Add API for communicating hide/show/resize from parents to interested children

[PolymerCommunityBot]

Issue by kevinpschaaf
Friday Oct 17, 2014 at 03:06 GMT
Originally opened as https://github.com/Polymer/polymer-dev/issues/113

---

There is a small class of elements that need to measure themselves to perform proper layout, when pure CSS alone is not sufficient (e.g. tooltip or virtual list). Since renderers skip layout when a subtree is display:none and measurements such as offsetHeight/offsetWidth return 0 in that case, such "measuring" elements must defer their measurement/layout until a point at which they (and all of their parents) are visible.

There is a general problem with the web platform in that there is no event/API an implementer can listen for to know when children have been hidden or shown by virtue of a parent being hidden/shown (e.g. by display:none on an inline-style or class), and so such elements have no way of knowing when to perform measurement and layout. A similar problem exists in that a child has no way of knowing whether it may have been resized outside of its purview, in which case its measurements may have been invalidated and need to be updated.

This task is to implement a best-effort API that two classes of elements can opt-in to using, to solve this platform deficiency. Strawman as follows:

1. "Measuring elements" (e.g. core-tooltip, core-list) would notify parents (via an event) of their interest in knowing when a parent may have hidden, shown, or resized its children
2. "Layout controlling elements" (e.g. core-pages, core-overlay) would notify children who have previously registered interest via above event when they change display or size of a child

Above strawman is clearly not silver bullet-- both measurer and measuree must opt in to same scheme, but could make common use cases with cooperating elements "just work."

[robdodson]

+1billion

[robdodson]

What about more lifecycle callbacks? core-animated-pages has a core-animated-pages-transition-prepare event that it fires but maybe elements could inherit from a common parent that has a willPrepare callback or something that core-animated-pages could call instead of firing that event? Then within that willPrepare callback, something like core-scroll-header-panel could call measureHeaderHeight on itself, or do any other work it needs now that it's no longer display: none

[kevinpschaaf]

New CoreResizer and CoreResizable mixins added in https://github.com/Polymer/core-resizable component. See docs for details.

The following elements were upgraded to use these mixins:

CoreResizer's:

• core-animated-pages
• core-overlay
• core-scroll-header-panel
• core-splitter

CoreResizable's

• core-tooltip
• core-list
• paper-dialog
• paper-tabs

[olemartin]

@kevinpschaaf Great! Do you know when this will be released?

[Andersmholmgren]

I'm not sure this is fixed in all cases. For example if you look at http://jsbin.com/kezito in chrome (latest) it shows no rows until you manually resize the window. If you try on firefox and safari they show 4 rows till the window is resized.

Note I am referencing the core elements directly from http://www.polymer-project.org/components which I assume is now 5.2

See http://stackoverflow.com/questions/27736325/how-to-use-core-scroll-header-panel-with-core-animated-pages

[websemantics]

I've updated to latest 5.2, still have the same problem

[torsjonas]

@kevinpschaaf Will it also be added to core-pages (above Strawman point 2)?

I have a couple of forms in different core-page items and I want to set focus to the first input field of the form of whatever core-page item that is shown. Current workaround is a setTimeout.

[Andersmholmgren]

My workaround is to add a listener to the data object passed to core list and whenever it changes call updateSize. Works most of the time but not all

[kevinpschaaf]

@torsjonas The problem in the jsbin is actually not related to the resize/updateSize topic in this issue, it is because scrollTarget is not properly set (required when delegating scrolling to another element).

You are trying to put a core-list inside of core-scroll-header-panel's scrollable region. The core-list element can operate in one of two ways: it can either be sized and itself be overflow: auto to provide the scrollable region needed for a list to operate (default), or it can be left unsized and be placed inside another element with overflow:auto that is providing the scrollable region; in the 2nd case, you are required to set core-list's scrollTarget property to the element that is acting as the "scroller" for the list (this is where core-list gets its viewport size information and listens for scroll events). This requirement was clarified in the API docs recently in this commit: googlearchive/core-list@8c6574e, as a number of people hit their heads on this.

core-scroll-header-panel exposes its internal scrolling element as the scroller property. I have fixed your example to work properly, by facading the scrollTarget property of core-list out to list-test, and setting that to this.$.panel.scroller, the core-scroll-header-panel's scroller:
http://jsbin.com/qowaziciso/2/edit

Note, this is also the technique used in the sample in the core-list demos folder:

• https://www.polymer-project.org/components/core-list/demos/demo-messages-shp.html
• https://github.com/Polymer/core-list/blob/master/demos/demo-messages-shp.html#L148

[Andersmholmgren]

Thanks @kevinpschaaf for the detailed explanation. I am trying to apply this to my application.

One of my challenges is that my application is broken into several separate polymer elements (for modularity) which complicates things.

So to simplify things, I took the demo messages example you listed (which ui layout wise is very much what I'm trying to do) and attempted to evolve it into the structure I want. First I extracted the list and fab into a separate component but ran into a strange issue