On the (abominable) proposed HTML5 “scoped” attribute for style elements

Over the last couple of years, I’ve had my fair share to say about the direction HTML5 has been taking, in particular being quite critical of the entire approach taken to adding richer semantics to HTML, as well as specific language choices.

It must be said though, that nothing has quite riled me like the proposed “scoped” attribute for style elements. To learn about it, I recommend HTML5 doctor Jack Osborne’s much more readable version, with some thoughts (and lively commentary).

So, what do I think of it? Well, I guess from the title of the post you already know. I think this is genuinely the worst suggested feature of HTML or CSS I’ve ever seen, and I would like it to see it be swiftly taken out the back and euthanised. Yep — strong language, but just so no one is possibly mistaken about this.

Why am I so emphatically opposed to it? Where to begin? There are several different lines of objection I have.

First, if we consider the separation of presentation from markup to be in anyway important, and at present it is considered a central best practice in web development, then this approach, which strikes at the heart of that practice, should be anathema. It’s long been considered that inline CSS is a last resort hack when it is difficult, or impossible to apply style using a stylesheet in the head of a document (linked or embedded). Now we’re embedding style sheets into the body of a document?

But, let’s go even more deeply than that. The development of HTML5 is supposedly governed by core design principles. This suggested approach violates several of these. Let’s take a look.

Principle 2.2. Degrade Gracefully

So, what happens if we use this feature in current browsers? Well, firstly none of these support the feature whatsoever.

But here’s an example I tried in a number of current browsers

<section>
    <style scoped>
      p { color: red; }
    </style>
    <h2>How does it work?</h2>
    <p>Pellentesque habitant morbi tristique senectus et netus et malesuada fames ac turpis egestas.</p>
  </section>
  
  <p>other stuff</p>

And here’s what happened.

Safari 5.1, Opera 11, Chrome, Firefox 6, and IE7 up all recognise the style element, and then style both p elements red — so scoping is not honoured — let’s call this not graceful degradation.

Principle 2.3. Do not Reinvent the Wheel

We currently can scope style in an HTML document. We use these new fangled things call CSS selectors. Even without touching the HTML above we could style the paragraphs in the given section like so

section:first-of-type>p{
  color: red
}

Or we could add class or id as appropriate to our section. I’d need to see a pretty compelling use case here, that demonstrates a need that can’t otherwise be solved using existing CSS/​HTML practices and technologies, before beginning to even think there’s a problem to be solved, let alone that this might be a good solution to that problem.

Principle 3.1. Solve Real Problems

In over 15 years of web development, I’ve not seen a problem this is a solution to. If you are going to violate widely held long standing best practice, you need to do a bit better than invent a rare problem, then solve it in a way that opens the floodgates to terrible practice.

Truthfully, and I have paid a fair bit of attention for close to 15 years in the CSS space, I have never ever once heard anyone articulate this need. Sure, it’s probably happened, but it’s far from a pressing concern.

Principle 3.2. Priority of Constituencies

In case of conflict, consider users over authors over implementors over specifiers over theoretical purity

So, users get broken pages in older browsers with style scope. Authors who want to use it would need to hack around the fact that this not only doesn’t work in older browsers, it causes rendering challenges. Seems we are focussing at the level of theoretical “purity”, or maybe, the whims of specifiers here.

Is this what versionless HTML development is about? Design principles violated left right and center, and an unwanted, unneeded and harmful addition to HTML, seemingly at the whim of one of the authors of HTML5?

And the first place we hear about it is in a draft of the future HTML specification. I wonder what other hidden gems await discovery in that document?

You know, it’s not like there aren’t some pressing real world problems to there for HTML to address.

If you feel remotely strongly as I do, you can submit a comment on the draft HTML specification at the WHATWG here.

9 responses to “On the (abominable) proposed HTML5 “scoped” attribute for style elements”:

  1. Here’s why I like this idea, if not the particular execution:

    <style type=“text/css” scoped>
    @import url(blah.css);
    </​style>

    …which lets you apply CSS to a fragment of the document. That can be really handy when you’re bringing in someone else’s markup: you can bring in their styles as well. I’ve wanted to do this on more than one occasion over the past fifteen years. The use that springs to mind is including portions of a CSS support chart into another document.

    Of course, I’d prefer to do the same thing in the style attribute, as in style="@import url(blah.css);"—and I pushed to get that capability added to CSS, which it eventually was in the style attribute module—but whichever approach gets supported first will be fine with me. Maybe both will be at once and then I can ignore scoped styles in favor of the attribute.

  2. John makes some good points, particularly the issue of backward compatibility, but Eric’s use case is a compelling one.

    Importing a stylesheet to a specific scope with style="@import url(bla.css);" seems more intuitive. It’s also follows the well established pattern of being ignored by non-​​conforming browsers.

    • By: Phunky
    • September 15th, 2011

    I think there are a few interesting situations where this could be helpful, for example anything animated via JavaScript will usually jump all over the style attribute but this could allow the use of scoped stylesheets (external only, I still don’t like the inline ones) and could utilise classes instead of applying styles to multiple elements.

    It does feel dirty and it doesn’t degrade, but there is some reasoning behind the madness but its just not quite right.

    • By: John
    • September 16th, 2011

    John and Eric,

    the question is, is there literally no other solution to what appears to be a very edge case?

    At the very least, I’d suggest a link to an external style sheet, in place of embedded style.

    john

  3. Oh sure, there are other ways, like the style="@import url(blah.css);" approach. You could also imagine something like #myEl {apply-css: url(blah.css);} in a stylesheet. Either of those would do as well.

    My point was more I’d like to have that capability, and I’ll be happy whichever route delivers it. Plus I figure once the capability is in there, no matter which mechanism brings it, adapting any of the other, better approaches would be a relatively easy thing for implementors to do.

  4. This completely violates a years old patent application: http://​www​.google​.com/​p​a​t​e​n​t​s​?​i​d​=​y​l​n​J​A​A​A​A​E​B​A​J​&​a​m​p​;​p​r​i​n​t​s​e​c​=​a​b​s​t​r​a​c​t​&​a​m​p​;​s​o​u​r​c​e​=​g​b​s​_​o​v​e​r​v​i​e​w​_​r​&​a​m​p​;​c​a​d​=​0​#​v​=​o​n​e​p​a​g​e​&​a​m​p​;​q​&​a​m​p​;​f​=​f​a​lse

    • By: Joe
    • April 7th, 2012

    What about the XHTML and XML technologies, particularly attributes

    would be invalid XML along with the elements attributes.

    Valid would be

    • By: Brianary
    • January 10th, 2013

    Web content is rarely built of discrete monolithic documents by a single author or source anymore.

    Does it seem reasonable to you that you need to access the root CSS of the entire site to do some basic styling of a comment or other user-​​generated content, like right-​​aligning numeric table columns?

    Anyway, Firefox just added support for it: https://​bugzilla​.mozilla​.org/​s​h​o​w​_​b​u​g​.​c​g​i​?​i​d​=​5​0​8​725

    • By: James Edwards
    • April 13th, 2013

    If Firefox has added support for this, how come it doesn’t work …? (i.e. scoped style elements have no special properties, and continue to apply to the entire document, in Firefox 20). Have I missed something there?

    • By: normanzb
    • February 7th, 2014

    this attribute is quite useful when doing modular development, when you are developing a module which used by thousands of web pages, you have no idea whether the ‘section:first-of-type>p’ conflict with existing selectors on the “user“‘s page…

    and modular development for web is a quite common need, no matter when you are developing a reusable ui control, you can use scoped style. look at what’s happening, UI component developers are trying to avoid the naming conflict by adding a fragile prefix, wishing their prefix won’t conflict with others.

    don’t tell me iframe can do the same, iframe doesn’t, iframe is either too heavy or very hard to manipulate.

    you can easily style the wrapping element without naming conflict with scoped css, can you style the wrapping iframe easily without naming conflict?

Your opinion:

XHTML: You're allowed to use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>