On Thu, Jul 31, 2014 at 10:19 AM, cletusw <[email protected]> wrote: > I have a best practices question about Shadow DOM styling. In all the > <http://www.polymer-project.org/articles/styling-elements.html#element-defined-styles> > articles <http://robdodson.me/blog/2013/08/28/shadow-dom-styles/#theming> > I've > <http://robdodson.me/blog/2014/04/10/shadow-dom-css-cheat-sheet/#host> > seen > <http://www.html5rocks.com/en/tutorials/webcomponents/shadowdom-201/#toc-style-host>, > 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 > <http://www.polymer-project.org/docs/elements/core-elements.html#core-toolbar> > reacts to a *tall* class and becomes taller. Add a *mini* class to > paper-fab > <http://www.polymer-project.org/docs/elements/paper-elements.html#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 > <https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input#attr-type> > - *reversed* for ordered lists > <https://developer.mozilla.org/en-US/docs/Web/HTML/Element/ol#Attributes> > - *controls* for videos > > <https://developer.mozilla.org/en-US/docs/Web/HTML/Element/video#attr-controls> > > 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 > <http://www.polymer-project.org/docs/elements/paper-elements.html#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 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/CAPJYB1iQqv35rTkAusCzwFoieWam1jm2_uikvmoLBSo1TkUcog%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
