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.
On Mon, Apr 14, 2014 at 1:40 PM, Pascal Precht <[email protected]>wrote: > 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? > > 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/2147f5a3-2409-45cb-8993-1e4096b8837b%40googlegroups.com<https://groups.google.com/d/msgid/polymer-dev/2147f5a3-2409-45cb-8993-1e4096b8837b%40googlegroups.com?utm_medium=email&utm_source=footer> > . > 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/CAJj5OwC_WW6PVf2zEgGhZ%3DqYLZBJm%2BS1R7bHZxA8a5R4TwCJKw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
