Polymer 0.5 - how should position: fixed work in a scrollable element?

167 views
Skip to first unread message

Eric Eslinger

unread,
May 16, 2015, 9:02:42 PM5/16/15
to polymer-dev
I have two codepens:


and


Both are basic core-scaffolds that more-or-less do the same thing. There's a core-scaffold, inside the main is a small thing and a tall thing, so the core-header-panel in the scaffold has to scroll up and down.

In the first pen, there's a position: fixed element *inside* the <div main> element in the core-scaffold. This is a light dom element that's getting projected into the shadow root.

In the second pen, the position: fixed element is outside the <core-scaffold>. It renders how I would expect things - fixed to the bottom of the window, and the core-header-panel scrolls below it.

The thing is, according to the MDN documentation on position: fixed, I'd expect these two things to render the same way. A position fixed element should be as large as the window's viewport, and stuck to the bottom of the viewport. In this case, that's not happening. Instead, the position-fixed item inside the core-scaffold renders at the bottom of the viewport when it first draws, but subsequent scrolling makes it scroll up and down. Further, it's the width of its parent, rather than the width of the viewport.

Is this expected behavior?

At the end of the day, I want a classic "bottom-drawer" type of interface item here, but something which I can define inside the scroller (due to data scoping). I'd rather not have to manually add and subtract these things on the Body itself, as that messes up other event passing.

Eric Eslinger

unread,
May 17, 2015, 11:09:21 AM5/17/15
to polymer-dev
Some further investigation:

This behavior seems linked to this:

https://code.google.com/p/chromium/issues/detail?id=420534 which is marked as wontfix, and at this point looks like expected but bad behavior that's an outcome from the CSS 2.1 transform spec. 

The #mainContainer element inside core-header-panel has a transform: translateZ(0); attached to it, which "breaks" position: fixed elements inside it. If I manually disable it in the inspector, the fixed div works just fine. If I add html /deep/ #mainContainer {transform: none}, I can override this extra bit of styling, *but* that selector only works in chrome AFAIK. 

The transform seems to be in relation to some other bug about full-page repaints in scrolls (it references github.com/Polymer/core-header-panel/issues/27 in the sourcecode) but it doesn't seem like this is an optimal fix. 

e

Eric Eslinger

unread,
May 17, 2015, 11:25:51 AM5/17/15
to polymer-dev
however-however, this behavior seems to be back to what I want in polymer > 0.9, at least with paper-header-panel (I didn't check exactly the same thing, since there's no core-scaffold in 0.9, but it's really the scroller in the headerpanel that was causing issues anyway).

So, I guess just another reason to work on getting everything into polymer 0.9 or whatever ASAP.

daniele...@gmail.com

unread,
May 27, 2015, 5:01:38 AM5/27/15
to polym...@googlegroups.com

The fixes 9f9242f do not make it possible to create components, sons of "#mainContainer" in position: fixed
In the previous version the bug was not present.

Fixes 9f9242f code
#mainContainer {transform: translateZ(0);}

Consider solution code
#mainContainer {transform: translateZ(1);}

Reply all
Reply to author
Forward
0 new messages