Scoped style sheets.

# Andrew Fedoniouk (8 years ago)

One more thing about <style scoped />.

What would be a specificity of CSS rules in scoped style sheet? Question is in markup:

<html> <style> body #content p { color:red; } <body> <div #content> <style scoped> p { color:green; } </style> <p>what would be the color of this text?</p> </div> </body> </html>

It appears as <style scoped> should always be more specific than rules

in just a <style>.

Yes/no?

Contact us to advertise here
# David Hyatt (8 years ago)

On Jul 14, 2008, at 5:50 PM, Andrew Fedoniouk wrote:

One more thing about <style scoped />.

What would be a specificity of CSS rules in scoped style sheet? Question is in markup:

<html> <style> body #content p { color:red; } <body> <div #content> <style scoped> p { color:green; } </style> <p>what would be the color of this text?</p> </div> </body> </html>

It appears as <style scoped> should always be more specific than
rules in just a <style>. Yes/no?

My own opinion is that each scope should constitute a separate author
cascade level. This is how scoped stylesheets work in XBL. So yes I
agree with you and think the spec needs to be amended.

# Tab Atkins Jr. (8 years ago)

On Mon, Jul 14, 2008 at 5:50 PM, Andrew Fedoniouk news@terrainformatica.com wrote: >

One more thing about <style scoped />.

What would be a specificity of CSS rules in scoped style sheet? Question is in markup:

<html> <style> body #content p { color:red; } <body> <div #content> <style scoped> p { color:green; } </style> <p>what would be the color of this text?</p> </div> </body> </html>

It appears as <style scoped> should always be more specific than rules in just a <style>. Yes/no?

Hmm. It's certainly tempting to say, "exactly as normal", but that can cause a lot of problems. Part of the point of scoping is to state that you have special styles specifically for the scoped fragment, and having to deal with specificity issues all the time would be very annoying. It's likely to be a very common problem, as well, since the use of scoping means that you don't need the elaborate targetting preamble that is sometimes required in global styles (and thus your scoped styles will naively have a much lower specificity).

So, yeah, you'd want scoped rules to win over unscoped rules regardless of specificity. However, you have to address the interaction with !important. I believe it's most reasonable to still have !important rules ignore specificity and apply regardless, meaning that a global !important rule would override a scoped rule without !important.

Of course, a scoped !important rule would likely override a global !important rule, no?

~TJ

# Andrew Fedoniouk (8 years ago)

David Hyatt wrote:

On Jul 14, 2008, at 5:50 PM, Andrew Fedoniouk wrote:

>

One more thing about <style scoped />.

What would be a specificity of CSS rules in scoped style sheet? Question is in markup:

<html> <style> body #content p { color:red; } <body> <div #content> <style scoped> p { color:green; } </style> <p>what would be the color of this text?</p> </div> </body> </html>

It appears as <style scoped> should always be more specific than rules in just a <style>. Yes/no?

My own opinion is that each scope should constitute a separate author cascade level. This is how scoped stylesheets work in XBL. So yes I agree with you and think the spec needs to be amended.

We've met problem with that.

Say you have some component:

<div class="calendar"> <style scoped src="calendar.css" /> <table class="month-view">...</table> </div>

with the styling:

---- calendar.css ------------ td.week-name { color: ...; }

   td.today { border: ...; }     

Intention is to give the user (of our component) ability to tune up this styling a bit for his/her environment so to override some styles. E.g. user is willing to change td.today rendering.

In style sets that we use there is an inheritance mechanism for that - you can inherit authors set from another one and change styles there.

But in scoped html resided sets.... To be short: it should be something like important attribute:

<style scoped > - scoped styles first and page styles after.

<style scoped important > - page styles first and scoped styles after.

# Ian Hickson (8 years ago)

On Mon, 14 Jul 2008, David Hyatt wrote:

>

One more thing about <style scoped />.

What would be a specificity of CSS rules in scoped style sheet? Question is in markup:

<html> <style> body #content p { color:red; } <body> <div #content> <style scoped> p { color:green; } </style> <p>what would be the color of this text?</p> </div> </body> </html>

It appears as <style scoped> should always be more specific than rules in just a <style>. Yes/no?

My own opinion is that each scope should constitute a separate author cascade level. This is how scoped stylesheets work in XBL. So yes I agree with you and think the spec needs to be amended.

Actually XBL2 doesn't introduce a new cascade level. It just puts the sheets in an order that puts them before the sheets in higher scopes:

Sheets within each origin are always walked from the innermost shadow

scope to the outermost shadow scope (with rules in the outermost shadow

scope therefore overriding rules of equal specificity in the innermost

shadow scope). With this ordering a binding that defines a widget can

define a default look for the widget that can then be easily overridden

by a client of the widget. For multiple bindings attached to the same

element, the sheets are walked from the base binding to the most derived

binding.

-- www.mozilla.org/projects/xbl/xbl2.html#binding3

HTML5 doesn't say anything yet about how scoped="" interacts with the cascade; it just treats them like any normal author CSS rules.

I don't think we want to make them "stronger" than other rules. The normal specificity rules are enough to handle this. Otherwise we end up making authors of containing pages having to carefully use !important to override scoped styles, which seems like requiring excessive force.

# Andrew Fedoniouk (8 years ago)

Ian Hickson wrote:

On Mon, 14 Jul 2008, David Hyatt wrote:

One more thing about <style scoped />.

What would be a specificity of CSS rules in scoped style sheet? Question is in markup:

<html> <style> body #content p { color:red; } <body> <div #content> <style scoped> p { color:green; } </style> <p>what would be the color of this text?</p> </div> </body> </html>

It appears as <style scoped> should always be more specific than rules in just a <style>. Yes/no? My own opinion is that each scope should constitute a separate author cascade level. This is how scoped stylesheets work in XBL. So yes I agree with you and think the spec needs to be amended.

Actually XBL2 doesn't introduce a new cascade level. It just puts the sheets in an order that puts them before the sheets in higher scopes:

Sheets within each origin are always walked from the innermost shadow

scope to the outermost shadow scope (with rules in the outermost shadow

scope therefore overriding rules of equal specificity in the innermost

shadow scope). With this ordering a binding that defines a widget can

define a default look for the widget that can then be easily overridden

by a client of the widget. For multiple bindings attached to the same

element, the sheets are walked from the base binding to the most derived

binding.

-- www.mozilla.org/projects/xbl/xbl2.html#binding3

HTML5 doesn't say anything yet about how scoped="" interacts with the cascade; it just treats them like any normal author CSS rules.

I don't think we want to make them "stronger" than other rules. The normal specificity rules are enough to handle this. Otherwise we end up making authors of containing pages having to carefully use !important to override scoped styles, which seems like requiring excessive force.

Normal specificity rules will simply not work. To be able to overweight global styles you will end up with something like this:

<style> body.foo #content p { color:red; } </style> <body> <div #content> <style scoped> body.foo #content p { color:green; } </style> <p>what would be the color of this text?</p> </div> </body>

This will make scoped styles even more tied with the position of scoped element. To overweight the rule you will end with writing full paths of elements. The whole system of styles (global+scoped) will become even more fragile. At global level you will never be sure what will override what. The same thing is about scoped styles.

I propose to drop that <style scoped> feature then.

As, it seems, no one have clear idea of their purpose.

Otherwise we need to come up with at lest explanation of <style scope> goals. What kind of tasks they are aimed

to solve, etc.

For me personally <style scoped> is s "componentization"

feature. <style scoped> should allow to share components (DOM subtrees) accompanied with specific set of styles and without pollution of the whole system. This goal requires scoped styles to be isolated from the rest of the DOM. And yet to work effectively.

Ideally it should be possible to say something like this:

<form> Date of birth:<!--#include virtual="components/calendar.fhtml"--> </form>

and this should be sufficient to include the component (that is markup+styles+scripts).

# David Woolley (8 years ago)

Andrew Fedoniouk wrote:

Normal specificity rules will simply not work. To be able to overweight global styles you will end up with something like this:

Note that global rules have to be able to overrule scoped ones, otherwise you have lost the key requirement of the cascade that the consumer has ultimate authority.

(One thing that concerns me about the whole use case is that it is based on embedding what are really separete resources, for reasons that have to do with ensuring that advertisements are seen, not to do with the natural structure of the information. However the want to meet commercial constraints is so endemic these days, that I don't think I'd win such an argument amongst implementors. The real solution would be to make object work!)

# Ian Hickson (8 years ago)

On Mon, 14 Jul 2008, Andrew Fedoniouk wrote: >

Normal specificity rules will simply not work. To be able to overweight global styles you will end up with something like this:

<style> body.foo #content p { color:red; } </style> <body> <div #content> <style scoped> body.foo #content p { color:green; } </style> <p>what would be the color of this text?</p> </div> </body>

I don't think this is really realistic. If <div id="content"> is imported

from another source, why would the doc style sheet attempt to style it if the importing source is going to override it?

In fact, I'd suggest that it's the parent doc that is the one that is going to want to override styles. For that, this mechanism works fine.

# Lachlan Hunt (8 years ago)

David Woolley wrote:

(One thing that concerns me about the whole use case is that it is based on embedding what are really separete resources, for reasons that have to do with ensuring that advertisements are seen, not to do with the natural structure of the information. However the want to meet commercial constraints is so endemic these days, that I don't think I'd win such an argument amongst implementors. The real solution would be to make object work!)

Commercial cases like that aren't the only use cases for scoped stylesheets. Consider this use case.

A blog has a normal theme applied to all articles that covers the general styling issues quite well. But then the author publishes an article that requires some additional enhancements to be made, but the author wants to avoid inadvertently affecting the style of other articles.

Adding more rules to the site's global stylesheet, perhaps scoped by some unique article ID isn't really ideal because if it happens frequently, it causes the global stylesheet to be filled with lots of article specific styles. In some cases, the article author may not even have access to modify the global stylesheet.

The solution needs to work in all places where the article is listed, including on its individual page or in a monthly archive listing. The scoped stylesheet allows the author associate the set of styles with the article.

# Tab Atkins Jr. (8 years ago)

Andrew Fedoniouk news@terrainformatica.com wrote:

I propose to drop that <style scoped> feature then. As, it seems, no one have clear idea of their purpose.

No... Their purpose is quite clear, and has been explained in several ways by several people. They allow you to create a set of styles which can only affect a subset of the document.

Ian Hickson ian@hixie.ch

I don't think we want to make them "stronger" than other rules. The normal specificity rules are enough to handle this. Otherwise we end up making authors of containing pages having to carefully use !important to override scoped styles, which seems like requiring excessive force.

I disagree. In fact, your example is actually a reason for making scoped styles stronger than global styles. I'll state the two good reasons I see for making scoped styles automatically stronger than global styles.

1) In order to effectively target the desired element, a global style often needs a bit of targetting preamble before it gets down to the useful bit of the selector. Frex, if I'm styling the content of an article on my page, I need at the very least something like a #content preamble to ensure that my styling doesn't mess with the page template. That's a huge chunk of specificity right away that all styles have to overcome if they want to override my styles - if scoped styles compete on the same terms, then all of them must include at least one #id in their selectors to even have a hope of applying. If they are targetting similar things the useful part of the selectors are likely going to be the same, and so all of my scoped selectors need a special preamble (which likely involves reaching outside of their scope just to gather appropriate #ids) for the sole purpose of making sure they have enough specificity.

That is, I need to include useless information outside of my scope for every selector if I want to make sure they apply. Or I can just make them all !important, which makes it even more difficult (maybe impossible) for the site author to override the scoped styles when he really wants to.

Just to make it completely clear, take this document:

<style>

#content p { color: red; } </style>

<body> <header>header content...</header> <article id="content"> <style scoped> p { color: blue } </style> <p>article content...</p> </article> </body>

Imagine the article author doesn't have access to the global stylesheet, which is why he uses scoped styles to style his article. Since his styles are limited to the article itself, it makes sense that if he wants all <p>s

to be blue he'd just use a "p" selector to target them. However, his rule is overridden by the global style due to the specificity rules. He has to change his selector to "#content p" to make it work, even though his rules are already limited to the #content element. That is completely unintuitive, and partially negates the purpose of having a scoped style - that you don't have to worry about content outside of your scope. (We keep global matching for several reasons, but provide a ways to effectively ignore that with :scope when you want.) The style author wants all his <p>s

in scope to be blue, and he should be able to say that in a simple manner, without having to look up the global stylesheet to see just how specific he needs to make his selectors.

2) Your argument is that the global author should have an easy way to override the scoped styles. Why is this? Again, part of the purpose of scoped stylesheets seems to be to allow an author without access to the global sheets to still easily style their chunk of content. If the scope author is specifically styling a scoped section, why would the global author want to easily override their styles? This cripples a large chunk of the obvious use cases for <style scoped> right off the bat, and it does so

without the global author needing to specifically intend to do so. It's very easy to strongly override scoped styles by accident, purely because of the aforementioned targetting preamble that the global author is likely to use.

If it's vitally important that the global author enforce certain styles within a scoped block, I'd much rather it be an intentional decision. Requiring an !important rule is exactly that.

Now, a few comments. One might be tempted to say that scoped styles should exist in the normal cascade, but that :scope kicks them into a higher weight so that scoped authors can easily override if they wish. I don't think this is at all useful - really all you're saying is "always use :scope in your selector", and completely negating any benefit you may see in allowing the global author to easily override styles.

However, I can see the benefits of a two-tiered approach, where !important rules follow the normal cascade. As noted, a site author generally doesn't use !important rules unless they really want to make sure that something shows up the way they specify. Thus, it should be relatively difficult to override them. I can see the logic, then, in enforcing the full cascade so that global !important rules tend to be more powerful unless the scoped author goes out of his way to make sure his rules are more specific.

So, that was a whole lot of text for something fairly simple. I propose the following: Ordinary scoped rules are treated as having just greater weight than author rules (thus, lower weight than inline rules and such). !important scoped rules are treated as having the same weight as !important author rules.

# Brad Kemper (8 years ago)

On Jul 15, 2008, at 9:06 AM, Tab Atkins Jr. wrote:

Andrew Fedoniouk news@terrainformatica.com wrote: I propose to drop that <style scoped> feature then. As, it seems, no one have clear idea of their purpose.

No... Their purpose is quite clear, and has been explained in
several ways by several people. They allow you to create a set of
styles which can only affect a subset of the document.

That is already very easily done. This really seems more and more like
a solution in search of a problem.

# Tab Atkins Jr. (8 years ago)

On Tue, Jul 15, 2008 at 11:39 AM, Brad Kemper brkemper@comcast.net wrote:

On Jul 15, 2008, at 9:06 AM, Tab Atkins Jr. wrote:

Andrew Fedoniouk news@terrainformatica.com wrote:

I propose to drop that <style scoped> feature then. As, it seems, no one have clear idea of their purpose.

No... Their purpose is quite clear, and has been explained in several ways by several people. They allow you to create a set of styles which can only affect a subset of the document.

That is already very easily done. This really seems more and more like a solution in search of a problem.

Yes, it's easy for a site author to create selectors which target a section of a document. It's currently impossible (without a CSS parser/rewriter) to make a set of styles only target a section of a document, especially when the styles aren't written by the document author, but instead by end-users or middle-users (such as, say, people on a social network styling their individual pages).

In other words, it's intended to create a CSS sandbox, which is extremely difficult to achieve with current methods.

~TJ

# Brad Kemper (8 years ago)

On Jul 15, 2008, at 9:44 AM, Tab Atkins Jr. wrote:

On Tue, Jul 15, 2008 at 11:39 AM, Brad Kemper brkemper@comcast.net
wrote:

On Jul 15, 2008, at 9:06 AM, Tab Atkins Jr. wrote:

Andrew Fedoniouk news@terrainformatica.com wrote: I propose to drop that <style scoped> feature then. As, it seems, no one have clear idea of their purpose.

No... Their purpose is quite clear, and has been explained in
several ways by several people. They allow you to create a set of
styles which can only affect a subset of the document.

That is already very easily done. This really seems more and more
like a solution in search of a problem.

Yes, it's easy for a site author to create selectors which target a
section of a document. It's currently impossible (without a CSS
parser/rewriter) to make a set of styles only target a section of
a document, especially when the styles aren't written by the
document author, but instead by end-users or middle-users (such as,
say, people on a social network styling their individual pages).

In other words, it's intended to create a CSS sandbox, which is
extremely difficult to achieve with current methods.

~TJ

And is there really such a large hue and cry for such sandboxing of
CSS? It seems like a very limited use case, one that can (and probably
is) dealt with already by pre-processing the input before it is
published, and prepending something like #sandbox to the beginning of
each selector. There are many things I would much rather see the WG
and implementors spend their precious time on.

Especially because, as an author who often has to add my own CSS file
to HTML created by other companies, I do not want my hands tied via
sandboxing, and generally it has never been an issue from those
supplying the HTML. I have completely changed the look of their pages/ applications, and they had no problem with that.

# Ian Hickson (8 years ago)

On Tue, 15 Jul 2008, Tab Atkins Jr. wrote:

Just to make it completely clear, take this document:

<style>

#content p { color: red; } </style>

<body> <header>header content...</header> <article id="content"> <style scoped> p { color: blue } </style> <p>article content...</p> </article> </body>

I don't understand why anyone creating such syndicated documents would ever have any rules with #content in the selector as part of their global style sheet if they didn't want to override the syndicated style sheet.

2) Your argument is that the global author should have an easy way to override the scoped styles. Why is this?

Because in the case of a syndicated document stream, the article author writes and styles his content first, and then the syndicator takes those files and merges them, at which point he can do touch-ups. You don't publish the frame before you have the content. The person who writes the style sheet last is the one who should get the ability to easily override the styles.

# Tab Atkins Jr. (8 years ago)

On Tue, Jul 15, 2008 at 2:22 PM, Ian Hickson ian@hixie.ch wrote:

On Tue, 15 Jul 2008, Tab Atkins Jr. wrote: >

Just to make it completely clear, take this document:

<style>

#content p { color: red; } </style>

<body> <header>header content...</header> <article id="content"> <style scoped> p { color: blue } </style> <p>article content...</p> </article> </body>

I don't understand why anyone creating such syndicated documents would ever have any rules with #content in the selector as part of their global style sheet if they didn't want to override the syndicated style sheet.

To provide a default styling for the content. I would think it's preferable to style content in some way to go along with the site's theme, even if the article author can then style it differently.

2) Your argument is that the global author should have an easy way to override the scoped styles. Why is this?

Because in the case of a syndicated document stream, the article author writes and styles his content first, and then the syndicator takes those files and merges them, at which point he can do touch-ups. You don't publish the frame before you have the content.

You're limiting yourself to a very narrow use-case, one which doesn't seem to require the automated control that <style scoped> offers. If an article

is manually editted by the syndicator after the author is done with it but before the article is published, then it's trivial to go through and manually ensure that the given styles are targeted appropriately.

I had thought that the entire purpose of <style scoped> was to help out

when there is no manual editting, such as on a site primarily filled with user-generated content. In these cases one cannot possibly manually edit all the content that passes through, but allowing users the ability to style their content is still a desirable goal.

The person who writes the style sheet last is the one who should get the

ability to easily override the styles.

I agree, but I would think that the author of the scoped styles would be the last one to write a style in the user-generated content use-case that I thought this was addressing. Even in your provided case I would assume that the scoped styles were written well after the global site styles. (As noted previously, I assumed that global styles would target into the scoped area to provide a default styling, not to do a final styling.)

~TJ

# Andrew Fedoniouk (8 years ago)

Ian Hickson wrote:

On Mon, 14 Jul 2008, Andrew Fedoniouk wrote:

Normal specificity rules will simply not work. To be able to overweight global styles you will end up with something like this:

<style> body.foo #content p { color:red; } </style> <body> <div #content> <style scoped> body.foo #content p { color:green; } </style> <p>what would be the color of this text?</p> </div> </body>

I don't think this is really realistic. If <div id="content"> is imported from another source, why would the doc style sheet attempt to style it if the importing source is going to override it?

In fact, I'd suggest that it's the parent doc that is the one that is going to want to override styles. For that, this mechanism works fine.

As far as I understand global styles and scoped ones are supposed to come from different sources. Someone before provided example about user' style sheets on social network portals. Portal designers and users have little mutual knowledge about their style sets.

In this case if user will want to override default styles of the portal then he/she must to use as full path for styling as possible - to give more specificity to his/her CSS rules. And these sheets will break if portal authors will decide to change anything. Portal designers will never be sure about their styling system. One day their rules will override users sheets, next day - users will win.

So is my question again: what is the purpose of such peculiar style system organization?

As far as understand you it is just enough to prepend each style rule in that scoped thing by something like:

<div class="username"> <style> div.username <users rule1> { ... } div.username <users rule2> { ... } </style> ... content ... </div>

and you will have what you want. It works already so why that <style scoped> there at all?

Thanks,

# Andrew Fedoniouk (8 years ago)

Lachlan Hunt wrote:

David Woolley wrote:

(One thing that concerns me about the whole use case is that it is based on embedding what are really separete resources, for reasons that have to do with ensuring that advertisements are seen, not to do with the natural structure of the information. However the want to meet commercial constraints is so endemic these days, that I don't think I'd win such an argument amongst implementors. The real solution would be to make object work!)

Commercial cases like that aren't the only use cases for scoped stylesheets. Consider this use case.

A blog has a normal theme applied to all articles that covers the general styling issues quite well. But then the author publishes an article that requires some additional enhancements to be made, but the author wants to avoid inadvertently affecting the style of other articles.

Adding more rules to the site's global stylesheet, perhaps scoped by some unique article ID isn't really ideal because if it happens frequently, it causes the global stylesheet to be filled with lots of article specific styles. In some cases, the article author may not even have access to modify the global stylesheet.

That is:

The solution needs to work in all places where the article is listed, including on its individual page or in a monthly archive listing. The scoped stylesheet allows the author associate the set of styles with the article.

the whole point.

I have my article that is html fragment. This article is also accompanied by styles. I want to be able to define styles that are "rooted" to the article container. Such styles has to be independent from the position of my article on different sites.

# Jens Meiert (8 years ago)

On Tue, Jul 15, 2008 at 12:50 AM, Andrew Fedoniouk news@terrainformatica.com wrote: >

<html> <style> body #content p { color:red; } <body> <div #content> <style scoped> p { color:green; } </style> <p>what would be the color of this text?</p> </div> </body> </html>

It appears as <style scoped> should always be more specific than rules in just a <style>. Yes/no?

Yes, shouldn't it.

Just brainstorming, but don't scoped styles only make sense when the cascade is modified accordingly, especially when taking into account the "page owner wants to override author styles that are out of his control" scenario? And shouldn't it be considering rather impractical to change the way specificity is calculated (n,n,n,n,n instead of n,n,n,n), so that scoped styles might just require a different origin [1], like

  • user agent declarations
  • user normal declarations
  • author normal declarations
  • owner or author 2 normal declarations
  • author important declarations
  • owner or author 2 important declarations
  • user important declarations

I cannot tell what this actually means for implementations (on first sight, it looks backwards-compatible), but it might help resolving this issue.

On Tue, Jul 15, 2008 at 4:19 AM, Andrew Fedoniouk news@terrainformatica.com wrote: >

Normal specificity rules will simply not work. To be able to overweight global styles you will end up with something like this:

<style> body.foo #content p { color:red; } </style> <body> <div #content> <style scoped> body.foo #content p { color:green; } </style> <p>what would be the color of this text?</p> </div> </body>

Agreed, and wouldn't this drive scoped styles useless anyway, as simply allowing "style" elements to be used within "body" would mean the same? Given this case, @scoped should probably be dropped.

[1] www.w3.org/TR/CSS21/cascade.html#cascade

Want more features?

Request early access to our private beta of readable email premium.