Add example on how to use css frameworks

[treshugart]

For example: http://www.webpackbin.com/EJ_kDWEEG

[Hotell]

hmm this is not very good example from perf perspective

In the end, @import is still an anti-pattern and can be a performance problem in web components. So, it’s not a great solution.

https://www.smashingmagazine.com/2016/12/styling-web-components-using-a-shared-style-sheet/

[treshugart]

@Hotell it seems like it's that or don't use shadow dom. Unfortunately, at this point in time, virtual DOM requires it to work properly across components. CSS frameworks need to change here. Even , once supported, is only a short term solution. Maybe we could find a way to make this easier for consumers? I don't have any ideas yet, do you?

[Hotell]

Hmm

We are shipping it inline for instance, not the best way from Perf perspective, but the only viable at this moment for us https://github.com/wc-catalogue/blaze-elements/blob/master/packages/button/Button.tsx#L50

About the ShadowDom, without it no content projection === no point of using WC at all ( we tried to use Preact for element rendering, wrapped with vanilla JS but ditched that because projection wasn't possible )

[Hotell]

So maybe we should include both your solution and ours within docs, WDYT ?

[treshugart]

We are shipping it inline for instance, not the best way from Perf perspective, but the only viable at this moment for us https://github.com/wc-catalogue/blaze-elements/blob/master/packages/button/Button.tsx#L50

That is the canonical way to do styling in web components for the time being. What's the performance penalty? Do you have numbers here?

About the ShadowDom, without it no content projection === no point of using WC at all ( we tried to use Preact for element rendering, wrapped with vanilla JS but ditched that because projection wasn't possible )

Not sure what you mean by "without it no content projection === no point of using WC". Can you clarify, please?

So maybe we should include both your solution and ours within docs, WDYT?

I'm not sure I'd include my example. After reading the article, I don't think it'd be a good idea to advocate an antipattern, even though it works (tm). I like yours - this is what I normally do - and am curious as to what performance issues you're experiencing as this is the recommended way to do styling in web components. Would it be because your css file transitively brings in the Blaze button css? It looks like you're only bringing in just the css for the buttons, which is exactly what CSS frameworks should provide when I say "CSS frameworks need to change". It would seem on the surface that you're not doing anything wrong.

[freeman]

According the article linked above it seems going without a ShadowDOM seems the only practical way.
Is this an option that SkateJS would consider adding ? (maybe with only partial support for content projection - ie one slot only maybe ?)

[Hotell]

although not related to this issue, I agree that having option to not render into shadow root and still get projection capabilities via <slot/> would be a killer feature ( although style encapsulation would need to be handled via css modules or css in js - I'm fine with both )

[treshugart]

So there's this. It's a trimmed down version of Shadow DOM and has both content and style encapsulation. It's very limited, but you get similar semantics. I'm thinking about making it an official thing at some point.

[fredyagomez]

@treshugart @Hotell any update on this issue ? For users who are not using shadow-dom, what is the best practice to manage and encapsulate the WC-style? I was playing with inline-styling using objects and libraries to achieve this but don't know the best practice/new approaches ?

[treshugart]

@fredyagomez I don't think there's a best-practice here other than trying to align with the specs. In that case, using the ShadyCSS fill is probably that. I'm not sure if it's Skate's place to be recommending approaches. You can use most CSS in JS libraries with Skate, if you wanted to.

[fredyagomez]

...performance issues you're experiencing as this is the recommended way to do styling in web components

I think @treshugart you are referring here to the inline-styling approach correct?

For the pseudo shadow-dom

I'm thinking about making it an official thing at some point.

Would you clarify about the use case/main benefits to make it official?

[treshugart]

I think @treshugart you are referring here to the inline-styling approach correct?

Not necessarily. I'm recommending whatever approach works for you. I'd use ShadyCSS if possible.

Would you clarify about the use case/main benefits to make it official?

Installable NPM package that exports a mixin you use with your components that enables DOM encapsulation without CSS encapsulation.

[MikaAK]

The webpackbin is down @treshugart! I'm having troubles with this now because with the shadow dom enabled it seems global css doesn't effect the components and I'm unable to use something like tachyons.io. Is there a workaround?

[treshugart]

@MikaAK I have no idea how to put that into the new bin format, sorry about that. Essentially what it did was include whatever it needs into the shadow root. Browsers optimise the duplicate CSS across all shadow roots.

[MikaAK]

Ah so it's not a problem to include the same stylesheet multiple times? Won't it increase the payload by a few kb for each import though?

[treshugart]

What do you mean for each import? You have to inline it as text between <style>${css}</style> so our bundle should only contain it once.

[MikaAK]

@treshugart I think I'm a tad confused, correct me if I'm wrong but I would need to inline it in every component right?
If the file is quite big doesn't this cause a bit of duplication bloat in the component files?
I use tachyons.io for most things and it has a fair amount of classes so duplicating them over and over isn't ideal (currently have shadowroot turned off)

[treshugart]

If you use a bundler, it will be included once in your bundle and be referred to as a variable. No duplication happens here. The only duplication is at runtime, and the browsers will optimise this at the shadow root level if the styles are the same as ones they've encountered before.

If you aren't using shadow DOM, why not just append it to the head?