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 On Sat, May 16, 2015 at 9:02 PM Eric Eslinger <[email protected]> wrote: > I have two codepens: > > http://codepen.io/ericeslinger/pen/bdedgp > > and > > http://codepen.io/ericeslinger/pen/jPrPyy > > 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. > Follow Polymer on Google+: plus.google.com/107187849809354688692 --- You received this message because you are subscribed to the Google Groups "Polymer" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/CABsi40LMm49tqBZsbO2xBwhBuc%3DsAfrZP_bY-8-Ts5JJtJqZkw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
