When you have a few elements in your document the performance consideration of * is mostly irrelevant. In your shadow Dom you're in a document fragment and the same applies. Now, if you have lots of elements in your shadow Dom, you likely should reconsider how you split your components.
Yes, but I was more commenting on how '*' doesn't apply to everything since it doesn't pierce shadow-roots. ie 'Universal' itself, is sort of a misconception. It is sort of obvious, but it's worth pointing out, maybe.
But that actually depends: many CSS properties are inherited from the host node into the shadow DOM, if not overwritten in the shadow DOMs style. So in many cases '*' will apply to everything, though it will not select everything. E.g. querySelectorAll will not return stuff from document fragments, but a CSS rule with that selector may still apply to stuff in the fragments through inheriting.
No idea what that does to performance, though :D
Oh, one more comment on this:
Currently web components are predominantly used as a way of organizing stuff in web applications. In these cases the question is of little relevance since such applications usually have little global style and a lot compartementalized styles.
However, in the future web components are envisioned to also or primarily serve as independent re-usable widgets. Now if you have dozens of independent web components on a page and then mess around with '*' on the top level, you are probably asking for all kinds of trouble plus a potential performance impact.
Well, that is interesting. I just tried this on one of my apps by setting font-style to italics, and it affected some stuff inside my elements. I wonder how I missed that...I wonder if it was like that in v0 shadow-dom.
Yeah, afaik css custom properties have been the recommended way of changing style inside shadow-dom - I wonder if that performs better...and there's upcoming features more applicable to theming, right? (I've been out of the loop for a little while).
Yes, shadow parts. w3.org/TR/css-shadow-parts-1/
But that looks like it will take some time. There was another proposal for theming, @apply I think, but it turned out, that that doesn't really fly. Hence the delay. Shadow parts seems pretty clever and comprehensive, though. Let's hope :)
Right, I use @apply quite a lot since it's part of Polymer - v1 at least. It works as far as it goes, but I'm not sure it completely satisfies the theming use-case - well, not on its own anyway. Vaadin have a theming system which sounded quite clean - they did a presentation on that prior to the last Polymer summit - and I think there was a presentation on an alternative in the summit itself, iirc (perhaps it was the shadow parts thing, I forget).
We'll see :)
IIRC correctly Vaadin basically went ahead and support shadow parts for their components, but I'm not sure, quite some time, since I looked at it. The problem with apply is, that it gives the consumer no way to discern styles for stuff like :hover or parent classes. The comment developer has to invest a lot of thought and development to allow for such use cases.
What about shadow-dom?
When you have a few elements in your document the performance consideration of * is mostly irrelevant. In your shadow Dom you're in a document fragment and the same applies. Now, if you have lots of elements in your shadow Dom, you likely should reconsider how you split your components.
Yes, but I was more commenting on how '*' doesn't apply to everything since it doesn't pierce shadow-roots. ie 'Universal' itself, is sort of a misconception. It is sort of obvious, but it's worth pointing out, maybe.
Ugh, got it :-)
But that actually depends: many CSS properties are inherited from the host node into the shadow DOM, if not overwritten in the shadow DOMs style. So in many cases '*' will apply to everything, though it will not select everything. E.g. querySelectorAll will not return stuff from document fragments, but a CSS rule with that selector may still apply to stuff in the fragments through inheriting.
No idea what that does to performance, though :D
Oh, one more comment on this:
Currently web components are predominantly used as a way of organizing stuff in web applications. In these cases the question is of little relevance since such applications usually have little global style and a lot compartementalized styles.
However, in the future web components are envisioned to also or primarily serve as independent re-usable widgets. Now if you have dozens of independent web components on a page and then mess around with '*' on the top level, you are probably asking for all kinds of trouble plus a potential performance impact.
Well, that is interesting. I just tried this on one of my apps by setting font-style to italics, and it affected some stuff inside my elements. I wonder how I missed that...I wonder if it was like that in v0 shadow-dom.
Yeah, afaik css custom properties have been the recommended way of changing style inside shadow-dom - I wonder if that performs better...and there's upcoming features more applicable to theming, right? (I've been out of the loop for a little while).
Yes, shadow parts. w3.org/TR/css-shadow-parts-1/
But that looks like it will take some time. There was another proposal for theming, @apply I think, but it turned out, that that doesn't really fly. Hence the delay. Shadow parts seems pretty clever and comprehensive, though. Let's hope :)
Right, I use @apply quite a lot since it's part of Polymer - v1 at least. It works as far as it goes, but I'm not sure it completely satisfies the theming use-case - well, not on its own anyway. Vaadin have a theming system which sounded quite clean - they did a presentation on that prior to the last Polymer summit - and I think there was a presentation on an alternative in the summit itself, iirc (perhaps it was the shadow parts thing, I forget).
We'll see :)
IIRC correctly Vaadin basically went ahead and support shadow parts for their components, but I'm not sure, quite some time, since I looked at it. The problem with apply is, that it gives the consumer no way to discern styles for stuff like :hover or parent classes. The comment developer has to invest a lot of thought and development to allow for such use cases.
Very interesting, thanks.