Custom scroller

[blasten]

One of the requested feature:

• External scrollTarget (it currently works for paper-scroll-header-panel)
  • Listen & measure on parent div
  • Measure offsetTop & take into account

Also, I'm using the document scroll in the new layout elements: https://github.com/PolymerLabs/app-layout.

A few use cases:

• Support headers and footers #103

cc @frankiefu

[kevinpschaaf]

Generally speaking, concept is fine. General points:

It would be good to get team consensus on how elements that need references to user-supplied peer or parent nodes should expose API's to get the node reference from the user.

After talking to @cdata, it seems there are a few existing techniques used:

• accept JS reference (user must poke using imperative code after creation)
• accept ID reference (requires finding host and then selecting id in host's scope, not horrible but finding host is somewhat shaky ground)
• accept selector (same as ID, requires finding host)
• find node in parent by convention (e.g. parentNode.scroller; requires tight coupling, not awesome)
• accept hard-coded strings, i.e. window (doesn't scale to arbitrary nodes)
• auto-find element in tree based on style, e.g. parent with overflow (requires climbing composed tree, which requires different slightly skeezy techniques depending on native vs. shady DOM)

Judging by the current code, the scroller property currently accepts:

• "window" (hard-coded string)
• a JS reference to a node (poked imperatively after creation)
• will automatically take parentNode.scroller if it exists at attached time, or
• will fall back to this (the list itself)

I would like to discuss this a bit before we lock in an API here.

I'll make other comments inline.

[kevinpschaaf]

should be removeEventListener?

[blasten]

@kevinpschaaf sounds goo :) I'd love to discuss this in detail with @cdata. BTW: here's the code for custom scroll target as a behavior: https://github.com/PolymerLabs/app-layout/blob/master/scroll-behaviors/custom-scroller-behavior.html

[kevinpschaaf]

Yeah, I also want to get some core team input on the general topic as well.

[cdata]

@kevinpschaaf @blasten Regarding consensus on how to declare element siblings, cousins or ancestors for a given element...

Right now we have a few other elements that need to do similar things, and all of them are different implementations:

1. iron-label https://github.com/polymerelements/iron-label
2. paper-badge https://github.com/PolymerElements/paper-badge
3. paper-tooltip https://github.com/PolymerElements/paper-tooltip
4. iron-fit-behavior https://github.com/PolymerElements/iron-fit-behavior/blob/master/iron-fit-behavior.html#L38-L49
5. iron-dropdown https://github.com/PolymerElements/iron-dropdown/blob/master/iron-dropdown.html#L123-L130
6. paper-ripple https://github.com/polymerelements/paper-ripple

There are probably other examples. All examples fundamentally expect the same thing: a property that maps to an element reference, and in all cases the element is not expected to be a member of the host's Shadow tree. The following are sources of variation in implementations:

• The semantics governing which elements are valid values tend to differ.
• The name of the host attribute that refers to another element relates to the use case or implementation of the host.

It kind of seems to me that a primitive mechanism in Polymer core (perhaps something like special support for a property with type: Element) would be really helpful to have in this case.

At any rate, it would be really nice to be able to standardize this somehow. There seems to be a lot of overlap (granted not 100%) between implementations.

[blasten]

@cdata good. I like the idea of the Element type a lot. What do you think about this example: https://github.com/PolymerLabs/app-layout/blob/master/scroll-behaviors/custom-scroller-behavior.html

CustomScrollerBehaviorcurrently uses Object similarly to iron-dropdown, but it also accept the string window. In the case that we end up with Element, this behavior could use html instead of window to point to the document element.

[blasten]

I'm closing this PR in favor of Polymer.IronScrollTargetBehavior