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.
Great reading, every weekend.
We round up the best writing about the web and send it your way each Friday.