Best practices for styling web components

[stevenla...@gmail.com]

What I'm hoping to gain from this question is an idea of what those who are in the trenches believe is/are the best practices for styling web components (taking into account future specs).

There seems to be two competing philosophies in terms of styling web components. On one hand, we have the philosophy that all web components should encapsulate all their styles and you should not allow style sheets to penetrate them (aka. a style guide). On the other had, there's the philosophy that shared / common styles should penetrate web components so a style guide on a site can style them.

At the moment, penetrating web components with a style sheet is difficult and not performant, but the [constructable stylesheet proposal](http://tabatkins.github.io/specs/construct-stylesheets/) would fix those issues. However, encapsulated styles for web components could also be problematic as the more styles you put in a web component, the slower it is to parse every time it's used. 

So taking into account the probable future, which philosophy do you believe is or will become the best practice? 

As a secondary discussion: do you believe you would implement paper-styles the same way if constructable stylesheets were implemented? I.E. would you still encapsulate the paper styles inside of their web components or would you create a global style sheet that the paper web components would use (not just a style sheet full of variables)?

[Eric Bidelman]

> web components could also be problematic as the more styles you put in a web component, the slower it is to parse every time it's used.

At least in the case of Blink's shadow dom implementation, <style> are shared across instances of an element. This helped performance a lot when it was implemented 1-2 years ago. Can't find the master bug, but this one is somewhat related.

> philosophy that shared / common styles should penetrate web components so a style guide on a site can style them.

It still requires the author of the component to allow such styling (using a shared style module in Polymer or providing hooks in vanilla shadow dom). 

I think the philosophy that will ultimately be most useful for folks is if well-written components provide styling hooks via css custom properties. This is the approach Polymer has taken with style modules and what we've found most useful implementing our own elements. This approach might be the only option since /deep/ and ::shadow are going away in shadow dom v1.

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 polymer-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/60833755-8be6-492d-913d-b237551f24e3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[stevenla...@gmail.com]

From what I understand, styling hooks via css do not provide default styles for any elements inside of the web component. So authors of the component still have to allow such styling (and have to know that the styling exists) by defining their own rule that mimics or uses the hooks needed, either through custom properties or more often via mixins. Typically, that means that that a lot of the web components first lines of css will be something like `:host { @apply(--typography); } p: { @ apply(--paragraphy); }`.

So in the end, the component author has to allow the style to "penetrate" regardless of the implementation.

> I think the philosophy that will ultimately be most useful for folks is if well-written components provide styling hooks via css custom properties... This approach might be the only option since /deep/ and ::shadow are going away in shadow dom v1.

In current spec this is the case, but I'm curious of what you think if Constructable Stylesheets were implemented (the web component W3C group keeps pointing to them as a coming solution). If the web component could declare through JavaScript that it uses a shared stylesheet, would you still feel that custom properties are still the philosophy that will be the most useful or do you think constructable stylesheets would be a more useful philosophy? 

Constructable Stylesheets doesn't prevent the shared stylesheet from declaring custom properties that can be used, but it would mean the web component doesn't need to declare default styling on elements via mixins.

[Eric Bidelman]

On Wed, Jun 1, 2016 at 2:11 PM <stevenla...@gmail.com> wrote:

From what I understand, styling hooks via css do not provide default styles for any elements inside of the web component. So authors of the component still have to allow such styling (and have to know that the styling exists) by defining their own rule that mimics or uses the hooks needed, either through custom properties or more often via mixins. Typically, that means that that a lot of the web components first lines of css will be something like `:host { @apply(--typography); } p: { @ apply(--paragraphy); }`.

So in the end, the component author has to allow the style to "penetrate" regardless of the implementation.

I see it as an invitation more than a penetration. Essentially the component author is providing a styling API surface for their component. 

/deep/ and ::shadow were the penetration solutions, but other vendors felt outsider consumers of a component shouldn't be able to have this much control.

 

> I think the philosophy that will ultimately be most useful for folks is if well-written components provide styling hooks via css custom properties... This approach might be the only option since /deep/ and ::shadow are going away in shadow dom v1.

In current spec this is the case, but I'm curious of what you think if Constructable Stylesheets were implemented (the web component W3C group keeps pointing to them as a coming solution). If the web component could declare through JavaScript that it uses a shared stylesheet, would you still feel that custom properties are still the philosophy that will be the most useful or do you think constructable stylesheets would be a more useful philosophy? 

I'm not sure how much traction the Constructable Stylesheets proposal has received, but the Polymer team has been pushing for the ability to load stylesheets into shadowRoots for several years (https://bugs.chromium.org/p/chromium/issues/detail?id=313458). IMO, such a feature would be amazingly useful. Polymer currently has to do this work at the library level. It should be a platform feature.

 

Constructable Stylesheets doesn't prevent the shared stylesheet from declaring custom properties that can be used, but it would mean the web component doesn't need to declare default styling on elements via mixins.

On Wednesday, June 1, 2016 at 11:42:31 AM UTC-6, Eric Bidelman wrote:

> web components could also be problematic as the more styles you put in a web component, the slower it is to parse every time it's used.

At least in the case of Blink's shadow dom implementation, <style> are shared across instances of an element. This helped performance a lot when it was implemented 1-2 years ago. Can't find the master bug, but this one is somewhat related.

> philosophy that shared / common styles should penetrate web components so a style guide on a site can style them.

It still requires the author of the component to allow such styling (using a shared style module in Polymer or providing hooks in vanilla shadow dom). 

I think the philosophy that will ultimately be most useful for folks is if well-written components provide styling hooks via css custom properties. This is the approach Polymer has taken with style modules and what we've found most useful implementing our own elements. This approach might be the only option since /deep/ and ::shadow are going away in shadow dom v1.

On Wed, Jun 1, 2016 at 8:59 AM <stevenla...@gmail.com> wrote:

What I'm hoping to gain from this question is an idea of what those who are in the trenches believe is/are the best practices for styling web components (taking into account future specs).

There seems to be two competing philosophies in terms of styling web components. On one hand, we have the philosophy that all web components should encapsulate all their styles and you should not allow style sheets to penetrate them (aka. a style guide). On the other had, there's the philosophy that shared / common styles should penetrate web components so a style guide on a site can style them.

At the moment, penetrating web components with a style sheet is difficult and not performant, but the [constructable stylesheet proposal](http://tabatkins.github.io/specs/construct-stylesheets/) would fix those issues. However, encapsulated styles for web components could also be problematic as the more styles you put in a web component, the slower it is to parse every time it's used. 

So taking into account the probable future, which philosophy do you believe is or will become the best practice? 

As a secondary discussion: do you believe you would implement paper-styles the same way if constructable stylesheets were implemented? I.E. would you still encapsulate the paper styles inside of their web components or would you create a global style sheet that the paper web components would use (not just a style sheet full of variables)?

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 polymer-dev...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/60833755-8be6-492d-913d-b237551f24e3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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 polymer-dev...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/210d5a2a-e127-4bf3-93ce-55810706f82b%40googlegroups.com.