Please, more info about new releases

[oswaldofreitas]

Hey guys, first I want to say you I love Polymer and hope to use it in all my production projects.

But, as a passionate, wait for notices periodically while it's still in preview, and guess you need more community engagement like Angular, so keep developers informed about your steps would be nice.

For example, I saw you released 0.5.6, where can I found info about new features, bugs fixed, etc...

Which is the main channel to follow you? Twitter, Polymer site blog, e-mail list...

Thanks for this great and innovative sugar API

[arthurevans]

Hi Oswaldo,

Sorry, that's my fault. As far as I know, 0.5.6 has no changes except for some API doc corrections. We needed to cut a new release to fix a few errors on the website. Those updates will be pushed to the site as part of the 0.9 update in a few days.

Normally we try to be very proactive about putting out information about new releases, but right now we're working really hard on 1.0 and this kind of snunk out without any fanfare.

For most stuff, twitter and email will keep you informed. New blog posts are usually announced both places.

If you're interested in 0.8/0.9/1.0 and following the day-by-day changes to the repos, I recommend joining the Polymer slack channel (bit.ly/polymerslack to join). A lot of community members have joined over there, and it's the best way to keep up to date with the fast-moving status of the 1.0 release.

[ericeslinger]

There are definitely other changes in 0.5.6. When I went to push my code from the testing server to the live server (I know, docker...) installing against Polymer/core-components#~0.5.5 via bower did two things. One: nothing worked, because of #1524 and two: a lot of my internal styling broke. I'm not certain if it's changes to webcomponents.js (the 0.5.6 wanted 0.6 of webcomponents instead of 0.5) and shadow dom polyfills, but buttons were not sizing properly and some of my more complicated layouts weren't rendering right (a bottom-drawer type of thing was suddenly attaching to the top of the document instead of the bottom).

I can work on isolating the specific differences, but since they're probably all my fault (we're a little fast-and-loose with shadow dom stuff sometimes) and given the 0.9 train, I'm not sure it's useful.

[arthurevans]

What browser are you testing on? I wouldn't expect a polyfill change to affect layout on Chrome.

[ericeslinger]

It is definitely chrome- I tested on both beta and stable channels. There's
likely something else at work here (the element in question has a fixed
position, but seems to be attaching to a different parent than it did under
0.5.5). I'll dig a little deeper tomorrow and see if I can generate a nice
isolated case.

On Wed, May 13, 2015 at 12:38 PM Arthur Evans [email protected]
wrote:

What browser are you testing on? I wouldn't expect a polyfill change to
affect layout on Chrome.

—
Reply to this email directly or view it on GitHub
#1507 (comment).

[arthurevans]

Have you been able to isolate this? We updated polymer-project.org to 0.5.6 and we haven't seen any issues.

[ericeslinger]

I spent a while working on isolating a reproduction, and I'm pretty confident saying at this time that this is on my end. Starting with core-scaffold and playing around with fixed position divs, I ended up seeing in both 0.5.5 and 0.5.6, the same behavior with position:fixed divs inside the [main] selector on the core-scaffold (a nice similar test case to what I was experiencing) - those divs end up scrolling up and down rather than being pinned to the bottom of the browser window.

To be honest, I'm not sure what the "right" behavior is- I inherited this code in working form, and I suspect that there's some dodgy css being used (the wanted behavior is having the div, regardless of its location in the DOM, to be window-width and pinned to the bottom regardless of scrolling going on in the core-scroll-panel, and overlaying the core-menu in the drawer panel if that menu is locked open in wide mode)

I'll probably just end up keeping my version pinned to 0.5.5 now and work on porting stuff properly into the .8/.9 libraries anyway, so you can close this out.

[ericeslinger]

It turns out this was not a webcomponents issue, but instead a core-header-panel one.

the fix for googlearchive/core-header-panel#27

added a transformZ() to the core-header-panel css, which breaks position: fixed styling - not precisely a "break" because it's apparently a wontfix bug in chrome due to some strange css spec, and the behavior is identical in firefox and safari

the issue: https://code.google.com/p/chromium/issues/detail?id=420534