Thanks everyone! On Tuesday, April 15, 2014 7:58:02 AM UTC+2, Don Olmstead wrote: > > 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. > > > On Mon, Apr 14, 2014 at 10:04 PM, Rob Dodson <[email protected]<javascript:> > > wrote: > >> 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]<javascript:> >> > 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] <javascript:>. >>> 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] <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/polymer-dev/CAJj5OwC_WW6PVf2zEgGhZ%3DqYLZBJm%2BS1R7bHZxA8a5R4TwCJKw%40mail.gmail.com<https://groups.google.com/d/msgid/polymer-dev/CAJj5OwC_WW6PVf2zEgGhZ%3DqYLZBJm%2BS1R7bHZxA8a5R4TwCJKw%40mail.gmail.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/96232e2f-d979-425f-965e-9f9672fbb611%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
