As you know, there is a lot more to building responsive websites than width. You need sensors that give you feedback to adjust sites based on other factors.

The best way to improve our feedback from your user’s sensor, or browser, is by using a JavaScript library called Modernizr. In this article I’ll explain why, when you go beyond width, Modernizr is such an invaluable tool.

In front-end development, developers used to adjust a site to fit the constraints of the layout engine used by a particular browser. In 2003, there were only three browsers: Netscape, Internet Explorer, and Opera. Firefox, Safari, and the first mobile browser, Opera Mini, were released by 2005. Chrome wasn’t released until 2008.

Currently there are five major browsers, each with its own mobile version. Across that array of browsers, there are also older versions that users haven’t upgraded. In the same way that creating multiple layouts for multiple screen sizes eventually becomes a zero sum game, so does building multiple front-ends for multiple browsers.

We’re using responsive web design to accommodate new, cutting edge mobile browsers. But, while accommodating new browsers, it’s important not to do so at the expense of older browsers.

Historically, optimization has come as a product of building a site for the most popular browsers and then tweaking to ensure the site looks the same on a set of popular browsers. Designs would have to accommodate the capabilities of all browsers.

Progressive enhancement is one strategy to cope with browsers’ failure to support modern features. There is a temptation to build for the most up-to-date features, but, in a responsive web, the design of a site is contextual to the frame that it’s being viewed through. Responsive web design has become popular because it resolves the most obvious changing context — the size of the frame — but the context of a browser runs much deeper than it’s viewport size.

SVG makes for a great solution for high-resolution displays, but what about its support in older browsers? It’s not supported in IE 8 or older, so you have to build in a fallback if you support that browser. You could identify the browser and serve alternative styles against that browser but then you would have to serve those same alternative styles for every browser that doesn’t support SVG.

Wouldn’t it be easier if you could just write a style that would be used against every browser that didn’t support SVG? That way, you wouldn’t have to keep up with bug reports from the users of older versions. You could just set the fallback once and forget it.

Traditionally, feature detection has been accomplished by detecting the browser’s user agent. This is done through JavaScript, using the navigator object. The navigator object dates back to the Netscape days and used to be a developer’s best tool in cross-browser compatibility.

If you have Chrome and have enabled DevTools, open your browser’s web inspector by right-clicking on a page and selecting Inspect Element. Then, click on Console and, after the caret, type “navigator.userAgent” and hit Enter. This will return your current browser’s user-agent, which is a string of text used to identify the browser in use. Chrome returns the following:

Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_2) AppleWebKit/537.35 (KHTML, like Gecko) Chrome/27.0.1443.2 Safari/537.35

In a lot of ways, the navigator object is the one of the best sensors we have available to us to inform our system about what our user is capable of; however, it’s not very future friendly. It bases your site’s actuators on a lot of assumptions about what the browser does and does not support. It also is unreliable because users can configure it to access sites that the browser might not be able to support.

What Modernizr does

Modernizr is a JavaScript library used to detect features in the browser. It’s loaded in the head of your page and runs during a page load. Adding it to your site is as simple as adding any other JavaScript library, such as jQuery, but, once added, Modernizer gives you an incredible amount of control in rendering your page and ensuring that every user is served a quality experience.

Having been loaded, Modernizr runs a series of checks against the user’s browser to determine what features the browser supports and creates a JavaScript object that you can use to test against. Modernizr doesn’t create support for these features; it simply gives you a way to provide fallback support for modern features. For example, in the case of SVG, Modernizr enables us to provide a fallback image for browsers that lack SVG support.

Modernizr also applies a set of classes to the HTML tag, giving you the ability to modify the page’s CSS using the corresponding CSS classes. These CSS classes allow you to use CSS systems to build actuators that will adjust your pages to allow the progressive enhancements available for a page.

As opposed to using the User Agent, Modernizr detects features directly by running a series of JavaScript tests that return boolean (true or false) values. This dictates the classes that are set to the html tag and gives you the ability to use JavaScript to detect whether a feature is available.

Installing Modernizr

Installing Modernizr is as simple as linking to the JavaScript library in the head of your page, but where the installation process gets complicated is creating the version that you need. Modernizr is available for download in two versions, the development version and the production version.

The development version is a full 42 KB, uncompressed file. This version is great if you’re well versed in JavaScript and want to make some tweaks to the tests it performs. Because it’s uncompressed, it’s easy to read and augment but it’s best left to developers with a firm understanding of JavaScript.

For those of you who might not be completely adept at JavaScript, or would like to quickly build a customized version of Modernizr, this is where the production version of the library comes into play. The production version building tool on the site gives you the ability to create a version with only the tests you require.

This comes in handy when you know you only need a certain set of tests. For instance, your site might not take advantage of CSS box-shadows, but it might need to support CSS gradients. Using the build tool, you can include the tests you need and exclude the ones you don’t need, keeping the source code trim and your user’s total load time down.

For our example, I’ll be working of the development version. I find that when I’m building a site, it’s best to work with the full version and then once you know what features you’ll be using in your site, trim the version down.

Using Modernizr for cross-browser CSS

Let’s do some simple feature detection with Modernizr. We’ll start with a raw sample site.

<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<script type="text/javascript" src="js/modernizr.min.js"></script>
</head>
<body>
</body>
</html>

Let’s use this small test to detect whether or not our browser is capable of supporting SVG. For the sake of simplicity we’ll just add two span tags to the page to detect support.

<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<script type="text/javascript" src="js/modernizr.min.js"></script>
<style type="text/css">
.yes{color:green;}
.no{color:red;}
span{display:none;}
.svg .yes{display:inline;}
.no-svg .no{display:inline;}
</style>
</head>
<body>
<div>
<span class='yes'>Huzzah! You have SVG support.</span>
<span class='no'>BOO! You don't have SVG support.</span>
</div>
</body>
</html>

If you test this in a browser that supports SVG, you’ll see the message “Huzzah! You have SVG support.” whereas if you have a browser that fails to support SVG, you’ll find the “BOO! You don’t have SVG support.” message.

This example is pretty rudimentary, but it displays the core idea of using Modernizr to fix cross browser issues. If we were doing this same fix using the old user agent method, we would have to have a style sheet for each browser that doesn’t support SVG and change our CSS for each one. (For anyone interested, the only major browsers lacking SVG support are Internet Explorer 7 and under.)

By adding the svg/no-svg class to the html on the page, your CSS now has a selector that can be used to override existing CSS rules. Because it’s on the parent-most tag, it can used to override other classes on the page.

So, in this case, both span tags are given display:none;. If there is no SVG support, the display:inline declaration on the span tag with the .no class overrides the display:hidden thanks to the no-svg rule on the html tag.

Let’s try a more useful example of the same idea. We might want to have an SVG background image on the page, which falls back to a PNG if the browser doesn’t support SVG. By default we’ll use the PNG image. This way, the SVG isn’t served unless it’s needed and becomes a progressive enhancement.

<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<script type="text/javascript" src="js/modernizr.min.js"></script>
<style type="text/css">
.skull{
width:300px;
height:300px;
background-image:url(images/skull.png);
background-size:100% auto;
background-repeat: no-repeat;
}
.svg .skull{background-image:url(images/skull.svg);}
</style>
</head>
<body>
<div class='skull'></div>
</body>
</html>

Now we have an awesome SVG skull that will look awesome and crisp for users with high-resolution displays, and still look good for users with older browsers.

Summary

There is a great wealth of information to be learned about Modernizr. We showed you how it does the work of cross-browser capability without having to remember or maintain a running list of which browsers support SVG.

It functions exceptionally as a system with which to serve your user actuators to create speedy and highly functional websites.

Do you use Modernizr in your projects? What other methods have you used for serving responsive content? Let us know in the comments.

Featured image/thumbnail, divergent lines image via Shutterstock.

MacDojo’s Mac Shortcuts Pro Course – only $27!

Editor’s Note: This article features techniques that are used in practice by Yahoo! and question coding techniques that we are used to today. You might be interested in reading Decoupling HTML From CSS by Jonathan Snook, On HTML Elements Identifiers by Tim Huegdon and Atomic Design With Sass by Robin Rendle as well. Please keep in mind: some of the mentioned techniques are not considered to be best practices.

When it comes to CSS, I believe that the sacred principle of “separation of concerns” (SoC) has lead us to accept bloat, obsolescence, redundancy, poor caching and more. Now, I’m convinced that the only way to improve how we author style sheets is by moving away from this principle.

For those of you who have never heard of the SoC principle in the context of Web design, it relates to something commonly known as the “separation of the three layers”:

• structure,
• presentation,
• behavior.

It is about dividing these concerns into separate resources: an HTML document, one or more cascading style sheets and one or more JavaScript files.

But when it comes to the presentational layer, “best practice” goes way beyond the separation of resources. CSS authors thrive on styling documents entirely through style sheets, an approach that has been sanctified by Dave Shea’s excellent project CSS Zen Garden. CSS Zen Garden is what most — if not all — developers consider to be the standard for how to author style sheets.

The Standard

To help me illustrate issues related to today’s best practices, I’ll use a very common pattern: the media object. Its combination of markup and CSS will be our starting point.

Markup

In our markup, a wrapper (div.media) contains an image wrapped in a link (a.img), followed by a div (div.bd):

    <div class="media">
      <a href="http://twitter.com/thierrykoblentz" class="img">
            <img src="thierry.jpg" alt="me" width="40" />
      </a>
      <div class="bd">
        @thierrykoblentz 14 minutes ago
      </div>
    </div>
    

CSS

Let’s give a 10-pixel margin to the wrapper and style both the wrapper and div.bd as block-formatting contexts (BFC). In other words, the wrapper will contain the floated link, and the content of div.bd will not wrap around said link. A gutter between the image and text is created with a 10-pixel margin (on the float):

    .media {
        margin: 10px;
    }
    .media,
    .bd {
        overflow: hidden;
        _overflow: visible;
        zoom: 1;
    }
    .media .img {
        float: left;
        margin-right: 10px;
    }
    .media .img img {
        display: block;
    }
    

Result

Here is the presentation of the wrapper, with the image in the link and the blob of text:

@thierrykoblentz 14 minutes ago

A New Requirement Comes In

Suppose we now need to be able to display the image on the other side of the text as well.

Markup

Thanks to the magic of BFC, all we need to do is change the styles of the link. For this, we use a new class, imgExt.

    <div class="media">
        <a href="http://twitter.com/thierrykoblentz" class="imgExt">
            <img src="thierry.jpg" alt="me" width="40" />
      </a>
      <div class="bd">
        @thierrykoblentz 14 minutes ago
      </div>
    </div>
    

CSS

We’ll add an extra rule to float the link to the right and change its margin:

    .media {
        margin: 10px;
    }
    .media,
    .bd {
        overflow: hidden;
        _overflow: visible;
        zoom: 1;
    }
    .media .img {
        float: left;
        margin-right: 10px;
    }
    .media .img img {
        display: block;
    }
    .media .imgExt {
        float: right;
        margin-left: 10px;
    }
    

Result

The image is now displayed on the opposite side:

@thierrykoblentz 14 minutes ago

One More Requirement Comes In

Suppose we now need to make the text smaller when this module is inside the right rail of the page. To do that, we create a new rule, using #rightRail as a contextual selector:

Markup

Our module is now inside a div#rightRail container:

    <div id="rightRail">
        <div class="media">
            <a href="http://twitter.com/thierrykoblentz" class="img">
                <img src="thierry.jpg" alt="me" width="40" />
            </a>
            <div class="bd">
                @thierrykoblentz 14 minutes ago
            </div>
        </div>
    </div>
    

CSS

Again, we create an extra rule, this time using a descendant selector, #rightRail .bd.

    .media {
        margin: 10px;
    }
    .media,
    .bd {
        overflow: hidden;
        _overflow: visible;
        zoom: 1;
    }
    .media .img {
        float: left;
        margin-right: 10px;
    }
    .media .img img {
        display: block;
    }
    .media .imgExt {
        float: right;
        margin-left: 10px;
    }
    #rightRail .bd {
        font-size: smaller;
    }
    

Result

Here is our original module, showing inside div#rightRail:

@thierrykoblentz 14 minutes ago

What’s Wrong With This Model?

• Simple changes to the style of our module have resulted in new rules in the style sheet.
  There must be a way to style things without always having to write more CSS rules.
• We are grouping selectors for common styles (.media,.bd {}).
  Grouping selectors, rather than using a class associated with these styles, will lead to more CSS.
• Of our six rules, four are context-based.
  Rules that are context-specific are hard to maintain. Styles related to such rules are not very reusable.
• RTL and LTR interfaces become complicated.
  To change direction, we’d need to overwrite some of our styles (i.e. write more rules). For example:

    .rtl .media .img {
        margin-right: auto; /* reset */
        float: right;
        margin-left: 10px;
    }
    .rtl .media .imgExt {
        margin-left: auto; /* reset */
        float: left;
        margin-right: 10px;
    }
    

Meet Atomic Cascading Style Sheet

a·tom·ic

/ə’tämik/

of or forming a single irreducible unit or component in a larger system.

As we all know, the smaller the unit, the more reusable it is.

“Treat code like Lego. Break code into the smallest little blocks possible.” — @csswizardry (via @stubbornella) #btconf

— Smashing Magazine (@smashingmag) May 27, 2013

To break down styles into irreducible units, we can map classes to a single style, rather than many. This will result in a more granular palette of rules, which in turn improves reusability.

Let’s revisit the media object using this new approach.

Markup

We are using five classes, none of which are related to content:

    <div class="Bfc M-10">
        <a href="http://twitter.com/thierrykoblentz" class="Fl-start Mend-10">
            <img src="thierry.jpg" alt="me" width="40" />
        </a>
        <div class="Bfc Fz-s">
            @thierrykoblentz 14 minutes ago
        </div>
    </div>
    

CSS

Each class is associated with one particular style. For the most part, this means we have one declaration per rule.

    .Bfc {
        overflow: hidden;
        zoom: 1;
    }
    .M-10 {
        margin: 10px;
    }
    .Fl-start {
        float: left;
    }
    .Mend-10 {
        margin-right: 10px;
    }
    .Fz-s {
        font-size: smaller;
    }
    

Result

@thierrykoblentz 14 minutes ago

What Is This about?

Let’s ignore the class names for now and focus on what this does (or does not):

• No contextual styling
  We do not use contextual or descendant selectors, which means that our style sheet has no dead weight.
• Directions (left and right) are “abstracted.”
  Rather than overwriting styles, we serve a RTL style sheet that contains rules such as these:

    .Fl-start {
        float: right;
    }
    .Mend-10 {
        margin-left: 10px;
    }
    

Same classes, same properties, different values.

But the most important thing to notice here is that we are styling via markup. We have changed the context in which we style our modules. We are now editing HTML templates instead of style sheets.

I believe that this approach is a game-changer because it narrows the scope dramatically. We are styling not in the global scope (the style sheet), but at the module and block level. We can change the style of a module without worrying about breaking something else on the page. And we can do this without adding any rule to the style sheet, let alone creating a new class and rule:

    .someBasicStyleForThisElementHere {...}
    

We get no redundancy. Selectors are not duplicated, and styles belong to a single rule instead of being part of many. For example, the style sheets that this page links to contain 72 float declarations.

Also, abandoning a style — for example, deciding to always keep the image on the left side of the module — does not make any of our rules obsolete.

Sound Good?

Not sold yet? I hear you saying, “This goes against every single rule in the book. This is no better than inline styling. And your class names are not only cryptic, but unsemantic, too!”

Fair enough. Let’s address these concerns.

Regarding Unsemantic Class Names

If you check the W3C’s “Tips for Webmasters,” where it says “Good names don’t change,” you’ll see that the argument is about maintenance, not semantics per se. All it says is that changing styles is easier in a CSS file than in multiple HTML files. .border4px would be a bad name only if changing the style of an element required us to change the declaration that that class name is associated with. In other words:

    .border4px {border-width:2px;}
    

Regarding Cryptic Class Names

For the most part, these class names follow the syntax of Zen Coding — see the “Zen Coding Cheat Sheet” (PDF) — now renamed Emmet. In other words, they are simple abbreviations.

There are exceptions for styles associated with direction (left and right) and styles that involve a combination of declarations. For example, Bfc stands for “block-formatting context.”

Regarding Mimicking Inline Styles

Hopefully, the diagram below clears things up:

Inline styles versus Atomic CSS.

• Specificity
  The technique is not as specific as @style. It lowers style weight because rules rely on a single class, as opposed to rules like .parent .bd {}, which clocks in at 0.0.2.0 (see “CSS Specificity: Things You Should Know”).
• Verbosity
  Most classes are abbreviations of declarations (for example, M-10 versus margin: 10px). Some classes, such as Bfc, refer to more than one style (see “Mapping” in the diagram above). Other classes use “start” and “end” keywords, rather than left and right values (see “Abstraction” in the diagram above).

Here are the advantages of @style:

• Scope
  Styles are “sandboxed” to the nodes they are attached to.
• Portability
  Because the styles are “encapsulated,” you can move modules around without losing their styles. Of course, we still need the style sheet; however, because we are making context irrelevant, modules can live anywhere on a page, website or even network.

The Path To Bloat

Because the styles of our module are tied only to presentational class names, they can be anything we want them to be. For example, if we need to create a simple two-column layout, all we need to do is replace the link with a div in our template. That would look like this:

    <div class="Bfc M-10">
        <div class="Fl-start Mend-10 W-25">
            column 1
        </div>
        <div class="Bfc">
            column 2
        </div>
    </div>
    

And we would need only one extra rule in the style sheet:

    .Bfc {
        overflow: hidden;
        zoom: 1;
    }
    .M-10 {
        margin: 10px;
    }
    .Fl-start {
        float: left;
    }
    .Mend-10 {
        margin-right: 10px;
    }
    .Fz-s {
        font-size: smaller;
    }
    .W-50 {
        width: 50%;
    }
    

Compare this to the traditional way:

    <div class="wrapper">
        <div class="sidebar">
            column 1
        </div>
        <div class="content">
            sidebar
        </div>
    </div>
    

This would require us to create three new classes, to add an extra rule and to group selectors.

    .wrapper,
    .content,
    .media,
    .bd {
        overflow: hidden;
        _overflow: visible;
        zoom: 1;
    }
    .sidebar {
        width: 50%;
    }
    .sidebar,
    .media .img {
        float: left;
        margin-right: 10px;
    }
    .media .img img {
        display: block;
    }
    

I think the code above pretty well demonstrates the price we pay for following the SoC principle. In my experience, all it does is grow style sheets.

Moreover, the larger the files, the more complex the rules and selectors become. And then no one would dare edit the existing rules:

• We leave alone rules that we suspect to be obsolete for fear of breaking something.
• We create new rules, rather than modify existing ones, because we are not sure the latter is 100% safe.

In other words, we make things worse because we can get away with bloat.

Nowadays, people are accustomed to very large style sheets, and many authors think they come with the territory. Rather than fighting bloat, they use tools (i.e. preprocessors) to help them deal with it. Chris Eppstein tells us:

“LinkedIn has over 1,100 Sass files (230k lines of SCSS) and over 90 web developers writing Sass every day.”

CSS Bloat vs. HTML Bloat

Let’s face it: the data has to live somewhere. Consider these two blocks:

    <div class="sidebar">
    

    <div class="Fl-start Mend-10 W-25">
    

In many cases, the “semantic” class name makes up more bytes than the presentational class name (.wrapper versus .Bfc). But I do not think this is a real concern compared to what most apps onboard these days via data- attributes.

This is where gzip comes into play, because the high redundancy in class names across a document would achieve better compression. And the same is true of style sheets, in which we have many redundant sequences:

    .M-1 {margin: 1px;}
    .M-2 {margin: 2px;}
    .M-4 {margin: 4px;}
    .M-6 {margin: 6px;}
    .M-8 {margin: 8px;}
    etc.
    

Caching

Presentational rules do not change. Style sheets made from such rules mature into tool sets in which authors can find everything they need. By their nature, they stop growing and become immutable, and immutable is cache-friendly.

No More .button Class?

The technique I’m discussing here is not about banning “semantic” class names or rules that group many declarations. The idea is to reevaluate the benefits of the common approach, rather than adopting it as the de facto technique for styling Web pages. In other words, we are restricting the “component” approach to the few cases in which it makes the most sense.

For example, you may find the following rules in our style sheets, rules that set styles for which we do not create simple classes or rules that ensure cross-browser support.

    .button {
        display: inline-block;
        *display: inline;
        zoom: 1;
        font-size: bold 16px/2em Arial;
       	height: 2em;
       	box-shadow: inset 1px 1px 2px 0px #fff;
       	background: -webkit-gradient(linear, left top, left bottom, color-stop(0.05, #ededed), color-stop(1, #dfdfdf));
       	background: linear-gradient(center top, #ededed 5%, #dfdfdf 100%);
       	filter: progid:DXImageTransform.Microsoft.gradient(startColorstr='#ededed', endColorstr='#dfdfdf');
       	background-color: #ededed;
        color: #777;
        text-decoration: none;
       	text-align: center;
       	text-shadow: 1px 1px 2px #ffffff;
       	border-radius: 4px;
       	border: 2px solid #dcdcdc;
    }
    .modal {
        position: fixed;
        top: 50%;
        left: 50%;
        -webkit-transform: translate(-50%,-50%);
        -ms-transform: translate(-50%,-50%);
        transform: translate(-50%,-50%);
        *width: 600px;
        *margin-left: -300px;
        *top: 50px;
    }
    @media \0screen {
        .modal {
            width: 600px;
            margin-left: -300px;
            top: 50px;
        }
    }
    

On the other hand, you would not see rules like the ones below (i.e. styles bound to particular modules), because we prefer to apply these same styles using multiple classes: one for font size, one for color, one for floats, etc.

    .news-module {
        font-size: 14px;
        color: #555;
        float: left;
        width: 50%;
        padding: 10px;
        margin-right: 10px;
    }
    .testimonial {
        font-size: 16px;
        font-style: italic;
        color: #222;
        padding: 10px;
    }
    

Do We Include Every Possible Style In Our Style Sheet?

The idea is to have a pool of rules that authors can choose from to style anything they want. Styles that are common enough across a website would become part of the style sheet. If a style is too specific, then we’d rely on @style (the style attribute). In other words, we’d prefer to pollute the markup rather than the style sheet. The primary goal is to create a sheet made of rules that address various design patterns, from a basic rule that floats an element to “helper” classes.

    /**
     * one liner with ellipsis
     * 1. we inherit hyphens:auto from body, which would break "Ell" in table cells
     */
    .Ell {
        max-width: 100%;
        white-space: nowrap;
        overflow: hidden;
        text-overflow: ellipsis;
        -webkit-hyphens: none; /* 1 */
        -ms-hyphens: none;
        -o-hyphens: none;
        hyphens: none;
    }
    /**
     * kinda line-clamp
     * two lines according to default font-size and line-height
     */
    .LineClamp {
        display: -webkit-box;
        -webkit-line-clamp: 2;
        -webkit-box-orient: vertical;
        font-size: 13px;
        line-height: 1.25;
        max-height: 32px;
        _height: 32px;
        overflow: hidden;
    }
    /**
     * reveals an hidden element on :hover or :focus
     * visibility can be forced by applying the class "RevealNested-on"
     * IE8+
     */
    :root .NestedHidden {
        opacity: 0;
    }
    :root .NestedHidden:focus,
    :root .RevealNested:hover .NestedHidden,
    :root .RevealNested-on .NestedHidden {
        opacity: 1;
    }
    

How Does This Scale?

We have just released a brand new My Yahoo, which relies heavily on this technique. This is how it compares to a few other Yahoo products (after gzip’ing):

Our style sheet weighs 17.9 KB (about 3 KB of which are property-specific), and it is shareable (unlike the style sheets of other properties). The reason for this is that none of the rules it contains relate to content.

Wrapping Up

Because presentational class names have always been deemed “out of bounds,” we — the community — have not really investigated what their use entails. In fact, in the name of best practice, we’ve dismissed every opportunity to explore their potential benefits.

Here at Yahoo, @renatoiwa, @StevenRCarlson and I are developing projects with this new CSS architecture. The code appears to be predictable, reusable, maintainable and scalable. These are the results we’ve experienced so far:

• Less bloat
  We can build entire modules without adding a single line to the style sheets.
• Faster development
  Styles are driven by classes that are not related to content, so we can copy and paste existing modules to get started.
• RTL interface for free
  Using start and end keywords makes a lot of sense. It saves us from having to write extra rules for RTL context.
• Better caching
  A huge chunk of CSS can be shared across products and properties.
• Very little maintenance (on the CSS side)
  Only a small set of rules are meant to change over time.
• Less abstraction
  There is no need to look for rules in a style sheet to figure out the styling of a template. It’s all in the markup.
• Third-party development
  A third party can hand us a template without having to attach a style sheet (or a style block) to it. No custom rules from third parties means no risk of breakage due to rules that have not been properly namespaced.

(Note that if maintenance is easier on the CSS side than on the HTML side, then the reason is simply that we can cheat on the CSS side by not cleaning up rules. But if we were required to keep things lean and clean, then the pain would be the same.)

Final Note

I was at a meetup a couple of weeks ago, where I heard Colt McAnlis say, “Tools, not rules.” A quick search for this idiom returned this:

“We all need to be open to new learnings, new approaches, new best practices and we need to be able to share them.”

(al, ea)

© Thierry Koblentz for Smashing Magazine, 2013.

               You can say a lot of things about the NSA. That it’s intrusive. That it’s Big Brother realized. That it’s a necessary evil in the changing game of national security.

               But one thing you can count on… this high tech megalith has its act completely together, right?

               Wrong.

               According to current and former U.S. officials, the NSA failed to update its anti-leak software at its Hawaii station before Edward Snowden’s now-famous antics.

               Apparently, the facility lacked the sufficient bandwidth to install the software before Snowden joined the team.

               At least the NSA can take comfort from knowing it’s not alone. In the years since the Chelsea Manning leak, the State Department has yet to even install adequate security software.

             It’s crazy that one of the great security leaks in government history was caused by a delayed a software update.

            Who could be so stupid…

             Which reminds us… better check our laptops, the last time we at USDemocrazy updated our software was about 2 years ago…