CSS Scoped Styles

By  on  

There are plenty of awesome new attributes we've gotten during the HTML5 revolution:  placeholder, download, hidden, and more.  Each of these attributes provides us a different level of control over an element on the page, but there's a new element attribute that allows control over several elements:  scoped.  The style element's scoped attribute allows developers to apply styles to only the host element and descendant elements -- a new level of control that CSS hasn't seen in several years.

The only difference in apply scoped styles is adding the attribute:

<style scoped>
    /* styles go here */
</style>

Scoped styles apply to the current element and descendant elements.  Inline styles still win out over scoped styles, so it's still best to avoid using inline styles, even when placing new scoped style elements in the page.  An example that illustrates the varying levels of styling could look like:

<div class="democontain">
	<style scoped>
		div { border: 1px solid green; margin-bottom: 20px; min-height: 40px; }
		.democontain { background: #f8f8f8; }
	</style>
	<div></div>
	<div style="border-color: pink;">
		<style scoped>
			div { background: lightblue; border: 1px solid blue; }
		</style>
		<div></div>
	</div>
	<div></div>
</div>

Scoped CSS

One interesting experiment result within Firefox Nightly shows that media queries within scoped styles work but only if the media query is a match during the page's initial render:

<style scoped>
@media only screen and (max-width : 1024px) {
	div { background: #000; }
}
</style>

This may be a bug as the feature has just recently been implemented.

This new scoped attribute is a hugely useful feature, especially for template creators, CMS users, and developers in a position where they cannot access a main stylesheet or simply don't want to create a new one.  A word of warning though -- style elements with the scope attribute can cause havoc on browsers which don't support the attribute, so use a decent polyfill if you're going to use them.

Recent Features

  • By
    Create Namespaced Classes with MooTools

    MooTools has always gotten a bit of grief for not inherently using and standardizing namespaced-based JavaScript classes like the Dojo Toolkit does.  Many developers create their classes as globals which is generally frowned up.  I mostly disagree with that stance, but each to their own.  In any event...

  • By
    JavaScript Promise API

    While synchronous code is easier to follow and debug, async is generally better for performance and flexibility. Why "hold up the show" when you can trigger numerous requests at once and then handle them when each is ready?  Promises are becoming a big part of the JavaScript world...

Incredible Demos

  • By
    Fixing sIFR Printing with CSS and MooTools

    While I'm not a huge sIFR advocate I can understand its allure. A customer recently asked us to implement sIFR on their website but I ran into a problem: the sIFR headings wouldn't print because they were Flash objects. Here's how to fix...

  • By
    Save Web Form Content Using Control + S

    We've all used word processing applications like Microsoft Word and if there's one thing they've taught you it's that you need to save every few seconds in anticipation of the inevitable crash. WordPress has mimicked this functionality within their WYSIWYG editor and I use it...

Discussion

  1. Definitely seems like a future that will be useful in the long-term future! To your point, I would hesitate to use it for the time being since it would have a huge negative impact on backward compatibility.

  2. Mike McNally

    Do you mean “descendant” instead of “ancestor”? Seems to me that the “ancestor” elements are those on the parent chain. If it does work that way then I need to lie down because that’s weird.

    • Yes sir! Whew, I had to pray about that for a moment too!

  3. One thing I don’t understand about these attributes…

    Way back in the day, I could do something like:

    Nowadays, I’m supposed to do:

    By the same logic, shouldn’t it be:

    or something like that?

    • Ian Toltz

      Ok, the code I tried to put in got eaten. Woops.

      Let’s try this again.

      One thing I don’t understand about these attributes…

      Way back in the day, I could do something like:

      Nowadays, I’m supposed to do:

      By the same logic, shouldn’t it be:

      ——–

      Hopefully adding the ‘pre’ tags should have fixed this… But in case the code gets eaten again, basically my question is why I need to do e.g. checked=”checked” when making a checkbox, but I don’t need to do scope=”scope” for these new HTML5 attributes.

      or something like that?

    • Hi Ian,
      This isn’t an HTML5 sintax issue, this is a markup language sintax.
      In HTML and HTML5 boolean attributes [1] doesn’t need an explicit value.
      In XHTML, XML and XHTML5 attributes minimization aren’t allowed. [2]

      [1] http://www.w3.org/TR/html4/intro/sgmltut.html#h-3.3.4.2

      [2} http://www.w3.org/TR/xhtml1/#h-4.5

    • Ian Toltz

      Thanks for the explanation, Maujor. That makes sense. Back when I was first teaching myself HTML, XHTML was starting to come into vogue.

  4. I guess an immediate win is any id-based selector e.g. #foo .bar can go into a <style scoped> child of foo, and it doesn’t even break existing browsers (although of course you won’t get the performance benefit).

  5. As I mentioned before on HTML5Rocks. I only see a use for syndicated contents that comes with style. Otherwise we are redoing the same bad practice we have been avoiding for the past years; mixing HTML and CSS again.

  6. I wrote about this on CSS Tricks here (http://css-tricks.com/saving-the-day-with-scoped-css/) with a wee demo, and spoke about it at WordCamp. It pretty much goes over like a lead balloon every time. I just love a controversial element!

  7. The advantage of over using #foo “scoping” is that you don’t have to worry about #id conflicts if it’s 3rd party generated content…also, less typing, more legible.

    Also, “best practice” is practice. In some cases this “best” practice has become bad practice (dogma). Some styles aren’t reused/reusable, and certainly don’t belong in an external css file. Newer designers/coders barely consider what proper separation even means (i.e. they don’t “practice” at all).

Wrap your code in <pre class="{language}"></pre> tags, link to a GitHub gist, JSFiddle fiddle, or CodePen pen to embed!