Scoped Styles - potential performance hit?

[kaixin-hc]

Is your request related to a problem?

While not currently an issue, I'm not sure if vue components should rely primarily on scoped style. According to the documentation on scoped styles:

Scoped styles do not eliminate the need for classes. Due to the way browsers render various CSS selectors, p { color: red } will be many times slower when scoped (i.e. when combined with an attribute selector). If you use classes or ids instead, such as in .example { color: red }, then you virtually eliminate that performance hit. https://vue-loader.vuejs.org/guide/scoped-css.html#also-keep-in-mind

However, scoped styles can reduce the chance of accidentally affecting other elements with the same class name.

Currently, newer vue components use scoped style wherever possible. Should we move out of using scoped style where it is not necessary?

[jonahtanjz]

From the scoped CSS documentation, it does seem like vue-loader is recommending us to use global styles over scoped styles when possible.

Currently, newer vue components use scoped style wherever possible. Should we move out of using scoped style where it is not necessary?

A brief look at the vue-components shows that most of our components are fully using scoped styles, even when the selectors are targeting classes that will only appear within their respective files. In these cases, using global styles should be preferred. I'm leaning towards moving these CSS out of scoped styles (except those that really need to be scoped) as there is not much benefit in using it.

@ang-zeyu would like to get your input on this.

[ang-zeyu]

There hasn't really been a clear direction on this so far unfortunately, iirc we've just been mostly adopting the prior patterns of the original vue-strap project.

I'm open to going either way, tending toward global namespaced styles as well; It would definitely be nice to standardise this!

I don't think the performance impact is significant in our case however, at least we haven't really noticed anything, as our number of components / stylesheets are really small. The advice is likely targeted at general web apps relying on 101+ stylesheets in which case I would imagine the impact is actually measurable. So any attempt at this should be motivated by standardisation (also taking the opportunity to namespace our styles 😁).

My only concern otherwise is that any PR attempting to tackle this will need to be extremely careful, it'll likely be quite a rigorous conversion that can come in multiple prs. Some issues for example:

• Scoped styles isolate not only the application of styles to the component but also isolate child selectors to the same component (hence the need for "deep selectors" too)
• Scoped styles are internally achieved via an attribute selector, this affects its specificity. (may interfere with global styles such as bootstrap's)

[gerteck]

I wanted to raise an issue about this but realized it was a known issue. I wanted to add some context and understanding, and summarize the discussion, for future developers who might work on this issue:

Issue: Some Vue components are using scoped styles. (e.g. submenu) Some vue components are not using scoped styles. (e.g. pic). Currently, there is no clear direction to use or not. So the usage of scoped in vue components styling is inconsistent now.

Benefit of using scoped:

• If not scoped, class names and css used can leak globally, and can affect user specified elements and classes in the rare case they use the same class name.

Here, I use the example of styles defined in Pic.vue, and show how the non-scoped style could theoretically be an issue.

Hence, if it is scoped, there will not be any unwanted global css effects. (Second row)

Disadvantage of using scoped:

• Performance hit of scoped. vue, vue-loader
• Styling becomes more intentional and deliberate, making it harder. This is because to affect child components (E.g. slotted content, other components) selectors such as deep need to be used. deep

Moving forward:

• Consider impact on performance and decide accordingly.
• If choosing to not scope, rather the focus should be on standardization across components, and standardizing namespacing of styles used, and perhaps adding this in the documentation to be known to users.

So any attempt at this should be motivated by standardisation (also taking the opportunity to namespace our styles)