On Wed, Jun 1, 2016 at 2:11 PM <[email protected]> wrote: > From what I understand, styling hooks via css do not provide default > styles for any elements inside of the web component. So authors of the > component still have to allow such styling (and have to know that the > styling exists) by defining their own rule that mimics or uses the hooks > needed, either through custom properties or more often via mixins. > Typically, that means that that a lot of the web components first lines of > css will be something like `:host { @apply(--typography); } p: { > @ apply(--paragraphy); }`. > > So in the end, the component author has to allow the style to "penetrate" > regardless of the implementation. >
I see it as an invitation more than a penetration. Essentially the component author is providing a styling API surface for their component. /deep/ and ::shadow were the penetration solutions, but other vendors felt outsider consumers of a component shouldn't be able to have this much control. > > > I think the philosophy that will ultimately be most useful for folks is > if well-written components provide styling hooks via css > custom properties... This approach might be the only option since /deep/ > and ::shadow are going away in shadow dom v1. > > In current spec this is the case, but I'm curious of what you think > if Constructable Stylesheets were implemented (the web component W3C group > keeps pointing to them as a coming solution). If the web component could > declare through JavaScript that it uses a shared stylesheet, would you > still feel that custom properties are still the philosophy that will be the > most useful or do you think constructable stylesheets would be a more > useful philosophy? > I'm not sure how much traction the Constructable Stylesheets proposal has received, but the Polymer team has been pushing for the ability to load stylesheets into shadowRoots for several years ( https://bugs.chromium.org/p/chromium/issues/detail?id=313458). IMO, such a feature would be amazingly useful. Polymer currently has to do this work at the library level. It should be a platform feature. > > Constructable Stylesheets doesn't prevent the shared stylesheet from > declaring custom properties that can be used, but it would mean the web > component doesn't need to declare default styling on elements via mixins. > > On Wednesday, June 1, 2016 at 11:42:31 AM UTC-6, Eric Bidelman wrote: > >> > web components could also be problematic as the more styles you put in >> a web component, the slower it is to parse every time it's used. >> >> At least in the case of Blink's shadow dom implementation, <style> are >> shared across instances of an element. This helped performance a lot when >> it was implemented 1-2 years ago. Can't find the master bug, but this one >> <https://bugs.chromium.org/p/chromium/issues/detail?id=538712> is >> somewhat related. >> >> > philosophy that shared / common styles should penetrate web components >> so a style guide on a site can style them. >> >> It still requires the author of the component to allow such styling >> (using a shared style module in Polymer or providing hooks in vanilla >> shadow dom). >> >> I think the philosophy that will ultimately be most useful for folks is >> if well-written components provide styling hooks via css custom properties. >> This is the approach Polymer has taken with style modules and what we've >> found most useful implementing our own elements. This approach might be the >> only option since /deep/ and ::shadow are going away in shadow dom v1. >> >> On Wed, Jun 1, 2016 at 8:59 AM <[email protected]> wrote: >> > What I'm hoping to gain from this question is an idea of what those who >>> are in the trenches believe is/are the best practices for styling web >>> components (taking into account future specs). >>> >>> There seems to be two competing philosophies in terms of styling web >>> components. On one hand, we have the philosophy that all web components >>> should encapsulate all their styles and you should not allow style sheets >>> to penetrate them (aka. a style guide). On the other had, there's the >>> philosophy that shared / common styles should penetrate web components so a >>> style guide on a site can style them. >>> >>> At the moment, penetrating web components with a style sheet is >>> difficult and not performant, but the [constructable stylesheet proposal]( >>> http://tabatkins.github.io/specs/construct-stylesheets/) would fix >>> those issues. However, encapsulated styles for web components could also be >>> problematic as the more styles you put in a web component, the slower it is >>> to parse every time it's used. >>> >>> So taking into account the probable future, which philosophy do you >>> believe is or will become the best practice? >>> >>> As a secondary discussion: do you believe you would implement >>> paper-styles the same way if constructable stylesheets were implemented? >>> I.E. would you still encapsulate the paper styles inside of their web >>> components or would you create a global style sheet that the paper web >>> components would use (not just a style sheet full of variables)? >>> >>> 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/60833755-8be6-492d-913d-b237551f24e3%40googlegroups.com >>> <https://groups.google.com/d/msgid/polymer-dev/60833755-8be6-492d-913d-b237551f24e3%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/210d5a2a-e127-4bf3-93ce-55810706f82b%40googlegroups.com > <https://groups.google.com/d/msgid/polymer-dev/210d5a2a-e127-4bf3-93ce-55810706f82b%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/CACGqRCA9k5vSev-Jj%2B_x%2BJj2FQ0zsMcAbsA9ywuy%3DcAGdjVBZw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
