Question about web component styling best practices

[Pascal Precht]

Hi guys,

I have a question regarding styling of web components. I know that it's probably too early to talk about best practices, but we probably don't have to talk about best practices at all, rather about some good advices with arguments behind it.

Imagine the following scenario:

Let's say we have a web component, that abstracts a very nice header element for your mobile UI away. We apply according styles and everything works fine.

Now we have another component, which is a button component. The button component get's its styling too, but we also want to be able to use the button

component within the header component. Actually all we wanna do is aligning the button in the header component.

With Shadow DOM CSS we're able to style down to "n" shadow doms from an outer document. On the other hand, we're able to define host context specific styles.

Now what does that mean? In case of our scenario, we have two options:

1. We could decide to style the alignment for our button, than **can** be used in our header, through Shadow DOM CSS. Kinda like the way we always do, but with shadow dom css.

2. We could define context specific styles to the button component. So it actually "knows" about a possible header context where its living in.

My question is, what is here the better way to go? The first option feels more appropriate since we do it in that way today. We define a CSS module and another one and a parent

module declares how a child module behaves within that parent module. But since we're using new technologies here that give us new possibilities, I wonder if it's over a long term

more convenient to define context specific rules for a component and let it know about it's possible contexts.

Any thoughts on that?

[Martin Kleinschrodt]

I would go with option 1 since 2 seems to violate the encapsulation principle. A component should never have to care about which context it is used in. Specifically, your button component can not, without breaking encapsulation, know if it is embedded in a header or somewhere else.

Of course, writing selectors that penetrate shadow dom boundaries, does, in a way, also break encapsulation since the host element has to be aware of the internals of the styled element. A solid way to provide custom styling from outside an element without breaking encapsulation will be through styling hooks via css variables but I don't know how far along that spec is (see: http://www.html5rocks.com/en/tutorials/webcomponents/shadowdom-201/#toc-style-hooks).

In your case the best option is probably to let the header tell the button component 'Guess what, you're inside a header!' and then let the button handle context specific styling based on that. This is called theming and the spec actually provides a convenient way to handle this via :host(selector) and :host-context(selector) (See http://www.polymer-project.org/articles/styling-elements.html). However, depending on the use case this can be a very unwieldy solution as the button component has to be aware of and contain rules for all the different contexts it can be used in.

Just my 2 cents and I'd be very interested to hear what the polymer team has to say about this. In any case, if you haven't already, I suggest you read through the articles mentioned above. The entire series about shadow dom on HTML5rocks is pretty amazing.

[Rob Dodson]

I really like OOCSS and SMACSS so this is how I frame things in my head:

1. The parent can position the child inside itself. Whether that is absolute/relative positioning or adding margin to the child to get it to layout correctly.
2. The child should provide known hooks that the parent can manipulate. I think of these as kind of like the public properties and methods of a child. Since it's ok to use IDs with custom elements, perhaps we use those to indicate specific hooks and classes for groups. If you're piercing the shadow dom and styling something that has neither an id nor a class it should probably feel dirty.

3. Theming is a cool idea, we should explore this more. I don't think it actually solves the problem, but it might save you some work. For example, remember when Bootstrap had gradients on all of its buttons? Being able to set bootstrap to the "flat" theme doesn't answer the question of "how do I align this thing in my header" but it does save you from having to strip out those gradients.

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/2147f5a3-2409-45cb-8993-1e4096b8837b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Don Olmstead]

For the Polymer.dart library I work on I provide the bare minimum of styling required and instead style everything externally. Since I'm using Dart the theme is a different package that someone can download. If someone else wanted to make a theme they would just need to do something similar and create a package with it.

https://github.com/donny-dont/Pixelate-Flat

Not sure if this is the best way, and I'm certainly open to feedback if there's anything I'm doing wrong, but it might give you some ideas.

To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/CAJj5OwC_WW6PVf2zEgGhZ%3DqYLZBJm%2BS1R7bHZxA8a5R4TwCJKw%40mail.gmail.com.

[Pascal Precht]

Thanks everyone!