Styling Best Practices

[cletusw]

I have a best practices question about Shadow DOM styling. In all the articles I've seen, the :host() rule is either used to react to user states (:hover, :focus), or, for theming, to a class. My question is about this second case. For example, core-toolbar reacts to a tall class and becomes taller. Add a mini class to paper-fab and it becomes smaller.

Is there any native element precedent for this behavior? It seems to me that in native-land attributes are used to customize elements (even when appearance is altered):

• The global hidden attribute
• checked and indeterminate for checkboxes
• reversed for ordered lists
• controls for videos

If I were a designer and I came across a class="tall" on an element and couldn't find the corresponding definition in my stylesheets, I would probably delete it. And then I would be really confused when the element's appearance changed. On the other hand, if I came across a tall attribute, I would naturally assume that the behavior/styles related to that were internal to the element. I think paper-button has this right with its raisedButton attribute.

I have heard anecdotally that CSS attribute selectors are slightly slower than class selectors, but I think that even if this is the case, implementations could easily adapt if attributes became the defacto way to customize web components.

Thoughts?

[Elliott Sprehn]

On Thu, Jul 31, 2014 at 10:19 AM, cletusw <cle...@gmail.com> wrote:

I have a best practices question about Shadow DOM styling. In all the articles I've seen, the :host() rule is either used to react to user states (:hover, :focus), or, for theming, to a class. My question is about this second case. For example, core-toolbar reacts to a tall class and becomes taller. Add a mini class to paper-fab and it becomes smaller.

Is there any native element precedent for this behavior? It seems to me that in native-land attributes are used to customize elements (even when appearance is altered):

• The global hidden attribute
• checked and indeterminate for checkboxes
• reversed for ordered lists
• controls for videos

Indeed, it's unfortunate that native things didn't use classes. Classes were made for styling, but we didn't reserve any names for the platform so they just add attributes instead. In an ideal world we would have used classes for all styling purposes, and attributes that change styling would also add/remove classes which makes the platform self explaining.

 

If I were a designer and I came across a class="tall" on an element and couldn't find the corresponding definition in my stylesheets, I would probably delete it. And then I would be really confused when the element's appearance changed.

The style will be in the stylesheets for the element.

 

On the other hand, if I came across a tall attribute, I would naturally assume that the behavior/styles related to that were internal to the element. I think paper-button has this right with its raisedButton attribute.

I have heard anecdotally that CSS attribute selectors are slightly slower than class selectors, but I think that even if this is the case, implementations could easily adapt if attributes became the defacto way to customize web components.

Thoughts?

Attribute selectors are definitely slower than classes. This is a hard problem to fix because the ratio of attributes that apply styles vs attributes that don't apply styles is biased very heavily toward attributes that don't. Classes are different, they almost always apply styles, so you're less likely to make the engine spend a lot of time looking at lots of classes that do nothing. That is, :host([attr]) takes time proportionate to the number of attributes your users are adding, which is usually a lot more than classes.

From an implementation perspective Chrome/WebKit keep global maps of attribute selectors right now which means any component that uses one will make all other components compute style slower. Hopefully we can fix that shortly.

- E