<style scoped> vs @scope

Post by **jobbautista9** » 2025-12-17, 08:34

I've had a pretty short but interesting conversation with a Firefox developer about the new scoped styling (without the complexity of Shadow DOM) that mainstream browsers back which is @scope: https://mastodon.social/@jaffathecake/1 ... 3728992717

With Firefox 146 now supporting it I've decided to test it as <style>@scope</style> as you would with <style scoped>, even though <style> in <body> currently violates the spec (<style scoped> was a notable exception when it was still in the spec). I immediately ran into a pretty annoying difference, which is that you can't select the parent element with its tag name; you'd have to use the `:scope` pseudo-class (available in both scoped styling solutions). Even the * selector doesn't select it. I'm not sure if this is a bug or it's intended, but it certainly proves that @scope is not the adequate replacement for <style scoped> that Mozilla thinks it is, and bug #1542645 should be reopened, not duped to the @scope meta-bug.

Of course that's not just the reason why <style scoped> should be supported again. Having the scoping done in HTML instead of CSS would be lighter on the CSS parser, as the browser doesn't have to look inside the CSS to see that the styling is supposed to be scoped inside the parent element containing the <style>. I can also select <style scoped> from the DOM APIs, like querySelector, or getElementsByTagName and then using getAttribute. Not sure how I'd do those with <style>@scope</style> without ending up selecting an unscoped <style>.

Now there is an advantage that @scope has that is pretty useful and should probably be implemented by us for our own <style scoped> (since we are the only implementer left that has it therefore making our implementation the de-facto standard): limiting the scope itself. In the fediverse thread I've linked above the FF developer wanted for the scoped styling to not apply to a certain classed div under the parent element. While it's possible to just put another <style scoped> in that div and do a * { all: revert; } (worth noting that @scope doesn't support this kind of solution, another crucial difference), which works for the FF dev's example, this is not ideal and we probably should avoid having the child div fight its parent over its scoped styling.

I did try a :not(.not-prose) and :not(.menu-bar) in the first <style scoped> which would solve the problem of the child having to do its revert, but both didn't work for some reason. That way would probably invite too much redundancy anyway, and doing the scope limit as another attribute of <style> (like <style scoped limit="selector"> would allow one to use the DOM API via JavaScript to dynamically limit a scoped styling. Yet another reason why <style scoped> should be reconsidered in the spec!

Post by **Moonchild** » 2025-12-17, 10:08

I'm not entirely sure what you're suggesting here.

The whole premise behind <style scoped> is very straightforward to understand: the styling applied only affects the element and its children (i.e. the scope of the element). If you don't want specific children to be styled with the scoped style, then the scoped style CSS should itself have exceptions to exclude those elements, in true cascading logic fashion (element CSS > scope CSS > document CSS, and anything unstyled in the scope or element is inherited by default)... Making a selector an attribute of the <style> element is really kludgy and confusing to use.

Post by **jobbautista9** » 2025-12-17, 10:30

Yeah I would like it to be possible to exclude children within the <style> HTML tag itself as an attribute's value. But if that's not desirable then I guess using the :not psuedo-class is the only way... Btw I've finally figured out how to make that pseudo-class work for limiting my scoped styling without resorting to all: revert, and that's by using the child combinator (>) between the :not and the usual selectors. CSS really gives me headaches lol...

https://jsbin.com/toyozeveza/1/edit?html,css,output

EDIT: Apparently that snippet is still not functionally equivalent to @scope's limiting but I've found double negation to work it seems: https://jsbin.com/bifijafiqa/1/edit?html,css,output

Pale Moon forum

<style scoped> vs @scope

<style scoped> vs @scope

Re: <style scoped> vs @scope

Re: <style scoped> vs @scope