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!

HTML5 syntax dilemma

Manuel asked:

In theory, HTML5 syntax is very lazy but, in fact, when you write a HTML5 page you follow some conventions that originate in the XHTML era: lowercase code, double-quoted attribute values, properly closed elements, proper element nesting. While this practice is rational and admirable, some people take a further step towards a XHTML-style syntax: they don’t use attribute minimization and do terminate empty elements. Of course this further step is not necessary to write clear HTML5 code, but could be fostered if you look at the following points:

1. it makes [it] easier to upgrade legacy XHTML code (which represents the bulk of the web even if it’s generally served as text-html) to HTML5 (it’s just a matter of doctype change)
2. it makes [an] easier the shift to HTML5 for web developers, since they are generally used to write XHTML
3. it could set a coding standard in the field

What do you think about it?

I disagree. I think there’s nothing lazy about HTML5 syntax. You could say that it’s lazy that in HTML we write <hr> rather than <horzontalrule>, but the fact is, it’s a specified part of the language.

Furthermore, “legacy XHTML” code does not represent the bulk of the Web; 61% of the Web is HTML4 according to the Opera MAMA study in 2008.

But it doesn’t matter. You say tom-ay-toes, I say to-mah-toes; you like XHTML syntax, I like HTML syntax. They’re all the same to a browser, if served as text/html.

Cheers, Bruce

Sections within sections

Corey asked:

Don’t know if this has been asked before or not, as I couldn’t find anything to tell me otherwise. I read through the article and section information and understand more or less how they function, but I’m wondering if there is a case to be made about having a section within a section. Your article doesn’t really touch on whether this is appropriate or not.

The reason I ask is because I have a page that is broken into different parts (introduction, description, requirements, etc) that are all part of the same overall article. Now if I wanted to break down say, the requirements section into sub-sections (technical, stylistic, semantic, etc) would it be all right to wrap those sub sections in a section tag (that is within a section itself), assuming I put the correct header on it?

Thanks a bunch,

Yes, you certainly can nest <section>s — in fact, that’s pretty much exactly what <section> is for! If you look at the source of some of our more recent articles — e.g., this article or our microformats article — you’ll notice how we’ve split the article into sections.

In theory, using nested sections means that we’ll be able to do away with <h2>–<h6>, since a new heading level is implied with each nested section. In practice, however, it’s not as simple as that, so we suggest sticking with the usual <h1>–<h6> heading structure even if you decide to nest sections.

For your example, this code would be entirely appropriate:

<article>
  <h1>Article name</h1>
  <p>...</p>
  <section>
    <h2>Introduction</h2>
    <p>...</p>
  </section>
  <section>
    <h2>Description</h2>
    <p>...</p>
      <section>
        <h3>Technical</h3>
        <p>...</p>
      </section>
      <section>
        <h3>Stylistic</h3>
        <p>...</p>
      </section>
  </section>
  <section>
    <h2>Requirements</h2>
    <p>...</p>
  </section>
</article>

Each part of the <article> is wrapped in a <section>. The one exception might be the introduction, unless you are explicitly declaring a heading with it. You don’t always need a <header> element if it would only contain a single <h1>–<h6> element. In that case, the heading on it’s own will be fine. Bruce has a good post on the difference between articles and sections.

Hope that helps, Rich

Since we’re being semantic…

Rob asked:

HTML5 is working towards being more semantic, but I don’t think the <link/> tag is semantic at all…especially for stylesheets! Has anyone ever suggested changing the specification for the <style> tag to have an ‘src’ attribute that would point to the CSS file? Current:

<link rel="stylesheet" href="style.css" />

Suggestion:

<style src="style.css"></style>

I think most implementors would say that the current way works well enough. Breaking backwards compatibility for the sake of theoretical purity was where XHTML 2 was heading before it was finally curtailed. HTML5 takes stock of where we are, warts and all, and builds on that. (I feel your pain: I always want <img> to be <image>.)

Cheers, Bruce

Describing the content of <figure>

Sverri asked:

A lot of things can be presented as figures (everything from a simple quote to an information-dense canvas). The first thing that came to my mind was using e.g. a “type” attribute. For example:

<figure type="code css">
  <figcaption>Styling p tags</figcaption>
  <code>p { margin-bottom: 1em }</code>
</figure>

That would be a dead simple way of succinctly telling user agents, search engines, etc. what kind of content they can expect to find in the figure. However, since this is not valid HTML5 (as far as I know) how would you recommend describing the contents of a figure, so as to make it more accessible to non-human agents?

Thank you.

Bruce replied:

What would be the purpose of doing so? For example, it’s easy for a non-human agent to see that your example contains code, or that:

<figure>
  <video>...</video>
  <figcaption>...</figcaption>
</figure>

contains video, or that:

<figure>
  <img />
  <figcaption>...</figcaption>
</figure>

contains an image. So I’m not sure of the use case for a type attribute.

Sverri then responded:

The way I think about this is that figures are images of sorts, or embedded content. A “type” attribute (or perhaps a more aptly named “of” attribute) would be the equivalent of the “alt” attribute of img. It is extra information, and as such would not always be needed, but sometimes it can be an important part in how you present the content.

As for use cases:

• Aiding search engines better understand the content
• Browsers can use such information to make browsing the internet richer

I realize that you can use some other way of describing the content, such as titles, itemscopes or other ways of adding metadata. A dedicated, but optional, attribute for this would not be such a bad idea in my opinion.

To sum up, I suppose what I am getting at is that content in a figure is not always so well defined on its own. A snippet of code, for example, is given more meaning if it is in a context, such as “css”, “algorithm” or “while loop”.

I hope I am being clear enough in what I am saying.

Bruce followed up once more:

You are clear. There have been many such discussions during the development of HTML5 (and preceding versions of HTML). For example, why not have a <name> element for marking up people’s names, analogous to <time>? Why not have <geo> or <place> or <location>?

The use cases you describe (aiding search engines and browsers) are equally applicable.

But it comes down to two factors:

First, HTML is not a specialised language. It’s a generalised language, and there are some cases that can’t be marked up with the existing crop of elements. (There are already over a hundred.)

Second is that minting new elements and attributes isn’t “free”. It’s more for authors to remember (and get wrong), it bloats parsers in browsers, and it makes regression testing harder. So if a new addition to the language doesn’t solve a very common problem, it isn’t added to the language.

As you said, microdata/microformats/RDFa can be used to extend the language for specialised cases.

Thanks, Bruce

Web app buttons and toolbars: anchors, buttons, or commands?

Christian asked:

If you’re creating a toolbar for a web app, or perhaps even a “Share this page” widget, should one use anchors, buttons or commands?

A toolbar should be HTML5 <menu> with nested <command>s, but browser support is zilch. I’d use a list of buttons, personally. I think <button> is the right element to perform tasks that might need an “undo”, like “Tweet This” or “Delete Document”.

Bruce

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.