2.0 - Load order importance when using style mixins

[TomK]

Apologies if this should be posted in https://github.com/webcomponents/shadycss.

Description

Depending on the order you define custom elements, ShadyCSS mixins do not apply

Live Demos

These two demos show the importance of element load order with shadycss mixins. They both have markup using custom elements, then define the elements, then the same markup is repeated.

The discrepancy occurs when markup is placed before custom element definition.
Both examples show the mixins are applied correctly when the markup is placed after custom element definition.

Broken: http://codepen.io/oridan/pen/LRKqKV?editors=1000
The broken demo shows the mixin HAS NOT been applied where the x-item element is defined BEFORE the x-group element.

Working: http://codepen.io/oridan/pen/yadrmX?editors=1000
The working demo shows the mixin HAS been applied where the x-item element is defined AFTER the x-group element.

Expected Behavior

It is my belief that ShadyCSS mixins should be applied regardless of markup position and definition order. If for example the import of the element defining the mixin is delayed for some reason, this becomes a real world problem.

Versions

• Polymer: 2.0-preview
• webcomponents: v1

[TomK]

Please note: I've just updated the demos to remove some misleading pollution (thanks for the prompt @arthurevans)

[TomK]

@azakus as the assignee I wondered if you were available at some point to discuss this issue.
I've done some investigation into resolving this in https://github.com/webcomponents/shadycss and found a couple of points, but wanted to know your thoughts on performance implications. Would it be easier to write an associated issue on shadycss and issue some PRs, or could I reach out to you on polymer slack?

[TomK]

I have put together a much simpler demo: http://codepen.io/oridan/pen/edqMPO?editors=1000

Item B simply extends Item A with no other changes. Therefore it is my understanding they should both display exactly the same.

[dfreedm]

This is actually a bug in 1.x as well (when you enable shadowdom and native css variables): http://jsbin.com/puqunepiwi/edit?html,output

[dfreedm]

Closed for webcomponents/shadycss#21