Isn’t this bad practice?

For years, we’ve been told (and have actively told others) to separate content and presentation layers. So why would we introduce something that seems to go against everything we’ve been preaching?

The separation of these layers is still vitally important, but let’s look at a few use cases to shed some light on why this attribute has been introduced. Scoped style provides a W3C-approved way to:

• Add one-off CSS styles.
• Add user-defined styles to wiki or CMS content.
• Add theme-defined styles via CMS plugins.
• Keep syndicated content together (e.g., keeping example code together with the example).

How does it work?

In this section, I’ll show you how this new attribute will work when it gets rolled out to browsers.

<article>
  <h1>Style Scoped</h1>
  <p>The scoped attribute for the style element will eventually allow for you to include style elements mid-document. To do this, you must mark up your style element with the scoped attribute.</p>
  <section>
    <h2>How does it work?</h2>
    <p>Pellentesque habitant morbi tristique senectus et netus et malesuada fames ac turpis egestas.</p>
  </section>
</article>

Adding the scoped attribute

In the next example, we’ll change the foreground color of the second paragraph to red (from whatever was defined in the master CSS file):

<article>
  <h1>Style Scoped</h1>
  <p>The scoped attribute for the style element will eventually allow for you to include style elements mid-document. To do this, you must mark up your style element with the scoped attribute.</p>
  <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>
</article>

This screenshot shows how things might render in the browser:

Can I apply scoped to <link>?

While I was writing this article, Dr. Rich asked whether it was possible to add this attribute to <link> elements. Turns out you can’t, but I stumbled across this tidbit in the WHATWG mailing list:

You can use <style scoped>@import url(whatever);</style>

And this even enables you to add some specific styles ([be they embedded] or from another external sheet) on a per-use basis if the need arises. For example, a long dissertation relying on many quotes may benefit from adding stronger visual highlights on the <em> elements within the last quote to reinforce the final conclusion.

Backwards compatibility

Unfortunately, scoped style isn’t all puppy dogs and kittens.

Since this newly introduced attribute isn’t understood by current browsers, CSS rules in <style scoped> are just added to the page’s CSS. Therefore, if you were to include a scoped style block mid-page, its declarations would be applied to every matching element in the document, regardless of whether the element were inside or outside of the scope’s range.

For the sake of backwards compatibility, Louis Lazaris has suggested a brand new element called <scopedstyle>. This new element would only be recognised by supporting browsers and ignored by everything else. This way, scoped styles wouldn’t be added to the whole document. Instead, the browser would just throw away the unrecognised <scopedstyle> element and move on.

Browser support

Currently, the scoped attribute isn’t working in any of the browser alpha versions (Opera.Next, Mozilla Aurora, or WebKit nightly builds). There’s work in progress by Roland Steiner for support in WebKit.

Using <style scoped> today

So you’ve read this article and decided that you need scoped style in your life. What now? Well, just like every other new HTML5 thing, we have a polyfill for it. Simon Madine has created a jQuery scoped CSS plugin on GitHub.

You could also assign a CSS prefix to target the section of your document you want to style. You’d still be able to stick your styles inline, but you’ve also provided a fallback for the older browsers. In fact, Dr. Oli has done just that on his latest article. (View source and search for <div class="faint">.)

Opinions

There’s no denying that we’re breaking backwards compatibility by introducing <style scoped>. To me, this just doesn’t make any sense. I feel this needs to be addressed by either creating a new element like <scopedstyle> or using some protective mechanism like the <!-- and --> delimiters that have been used within <style> and <script> elements.

Let’s not end this article with negative sentiment, though. As with anything, it’s what you make of it. Scoped style is pretty plain vanilla, but if people abuse it, it’ll end up with a bad rap. Dr. Oli has spoken at length about his love for this attribute as it allows him to have live code examples with the CSS in <pre> and also in a <style scoped> within a <figure>.

So now it’s time for you to express your views. What do you think about the new scoped attribute? Do you think it has a future? Should it be fast-tracked into the spec? Or do you think it’s a waste of time that could ultimately end up mixing our content and presentation layers together again? Let us know in the comments!

Aside question

Lukasz asked:

I wonder if such use of aside tag inside section would be correct:

<section id="about">
  <h1>about me</h1>
  <p>blablabla</p>
  <aside>
    <h2>you can also find me on:</h2>
    <ul>
      <li><a href="#">twitter</a></li>
      ...
    </ul>
  </aside>
</section>

Thanks in advance for any help and keep up the good work!

Hard to give definitive advice without seeing the whole page, but it seems fine to me. See Mike’s article on <aside>.

In general, use <aside> for a section of a page that consists of content that is tangentially related to but separate from the surrounding content. In print, this would be a sidebar, pull-quote, or footnote. On a weblog article, this could be article metadata in the margin or the comments section.

If your social network links are main content, then <aside> isn’t the element (maybe <section>, maybe <nav>). If they’re just related content (i.e., they could be omitted when showing this page in a feed reader), then <aside> is a good choice.

peace – Oli

Blogging services

Patrick asked:

Do you have any suggestions to people implementing HTML5 on blogging services like Tumblr? The last time I checked, there are problems making HTML5 blogs on these sites:

• Tumblr – inserted iframe breaks HTML5 conformance
• Posterous – no Javascript allowed at the moment (according to their doc)
• Blogger – it doesn’t preserve my HTML5 DOCTYPE

Are there blogging services that don’t mess with the HTML5 markup?

I used to use Tumblr, and you can use HTML5 in your templates. But any new HTML5 elements (e.g., <section>) in your articles get munged, even using the “Raw HTML” setting. Unfortunately, I think that managed blogging services will probably be a little slow to adopt HTML5 (= fix the HTML5 errors they/their tools have), and you’ll have to use your own CMS for that level of control.

You can of course build your own theme for something like WordPress, and a little birdie did tell me that the latest version of WordPress has some HTML5 in its default template, so this might carry over into their hosted service. If you can’t wait and don’t have a server, remember that HTML5 is a sliding scale — I was using <div class="section"> with Tumblr for a while.

peace – Oli

Link stylesheet

Steve asked:

Hello, can we get rid of type=”text/css” when declaring a link rel=”stylesheet”?

Thank you and long live the web.

You certainly can do that. Same with including JavaScript:

<link rel="stylesheet" media="screen, projection" href="http://html5doctor.com/css/style.css">
<script src="http://html5doctor.com/js/html5.js"></script>

Thanks, Tom

ID attribute validation

Andrés asked:

Does the id attribute allows to begin with a number or a hyphen, unlike previous specs? Is there any set of character that aren’t allowed, besides space character?

There are three rules for the value of the ID attribute:

1. It must be at least one character long,
2. it must contain no space characters, and
3. it must be unique within the page.

So a hyphen would be valid as an ID value. It validates too. However, you may run into legacy stuff that hasn’t been updated yet (HTML Tidy, WYSIWYG plugins for a CMS, etc), so I’d advise testing within your workflow and in a browser (no idea if IE would barf on that, and it wouldn’t surprise me if it did).

peace – Oli

I’m so confused – article, header, footer, nav?

Benjamin asked:

Hey Doctor(s), I’m so confused right now.

I’ve been trying to implement HTML5 for my new blog and CMS, but having difficulties trying to figure out where advanced content should go. All the demonstrations and examples about HTML5 are over-simplified and just don’t include any real world information. For example, an article typically includes (in no particular order):

• Article
  • Title
  • Tagline
  • Tags
  • Avatar
  • Content
  • Links to child articles (eg. download, docs, demo)
    • Link Title
    • Link Avatar
    • Link Author Name
  • Links to recommended articles (related content)
    • Link Title
    • Link Avatar
    • Link Author Name
  • Article Author Details
    • Author Name
    • Author Avatar
  • Article Details
    • Published Date
    • Modified Date
  • Share Buttons

So all in all, way more complicated than the typical:

• Article
  • Article Title
  • Article Content

So say for example, where should all the stuff in the complicated (real-world) example go? Should the avatar go in the header, the article, or the footer? Or maybe even a details element? Should the navigation links to other articles be like: nav > ul > li > article > header > a > h1 With the a containing the link, and the h1 containing the article header? Should the post details (despite we want them display perhaps underneath the title, and before the content) be in a details element? And should that be within the header element or be below the header element? Should they use for example:

<dl>
  <dt class="published">Published At:</dt>
  <dd class="published">...</dd>
</dl>

or:

<ul>
  <li class="published">
    <label>Published At:</label>
    <span>...</span>
  </li>
</ul>

or something else? The second example seems to remove the duplication of the css class, but seems to add more complications though. Should those tag and article links in nav elements be inside the header? Or footer? Or just article? How many footers and headers can be in article?

I’m soo confused. Any help would be greatly appreciated? Perhaps the best help out there would be a detailed HTML5 example of the real-world article structure I posted above.

OK now, take a deeeep breath and relax. There, feeling a little better?

That’s a mammoth e-mail, so here are some basics to get you started:

• Start with a basic page before attempting something complex — don’t jump in the deep end.
• Look at websites in HTML5 Gallery and check their code.
• Look at the code for this site. Granted, it’s not perfect, but it’s pretty good, and we have a lot of the content you list.
• Use the most appropriate element for each piece of content, even if it’s not one of the new ones. (Hopefully it ends up being what you used before.) Perhaps our handy flowchart might help for that.

Some more specific answers:

“Should the navigation links to other articles be like: nav > ul > li > article > header > a > h1 With the a containing the link, and the h1 containing the article header?” The title of an article is not the same as an article, so it’d be wrong to use <article> or <header> here. I assume you didn’t use <h1> in navigation lists before, right?

“Should the post details (despite we want them display perhaps underneath the title, and before the content) be in a details element?” Possibly, if you wanted that interaction, but likely not as you probably want them visible all the time. See what the spec says about <details>. Decide on the semantics of each piece of content first. Worry about styling later.

“And should that be within the header element or be below the header element?” Header or footer seem like good places to put them. <label> is a caption for a form control, not an element to use whenever you need to label something.

I recommend you start with your HTML4 or XHTML1 knowledge and build on it. HTML5 is an evolution, not a revolution. In fact, I’d recommend you start out making a site in HTML4 with the HTML5 doctype (and validate it as HTML5), then change bits over time as you read each article on HTML5 Doctor and learn more

peace – Oli

Got a question for us?

That wraps up this round of questions. If you’ve got a query about the HTML5 spec or how to implement it, you can get in touch with us and we’ll do our best to help.