Using CSS 2.1 pseudo-elements to provide up to 3 background canvases, 2 fixed-size presentational images, and multiple complex borders for a single HTML element. This method of progressive enhancement works for all browsers that support CSS 2.1 pseudo-elements and their positioning. No CSS3 support required.

• Demo: Multiple Backgrounds with CSS 2.1
• Demo: Multiple Borders with CSS 2.1

Support: Firefox 3.5+, Safari 4+, Chrome 4+, Opera 10+, IE8+.

How does it work?

Essentially, you create pseudo-elements using CSS (:before and :after) and treat them similarly to how you would treat HTML elements nested within your target element. But they have distinct benefits – beyond semantics – over the use of nested HTML elements.

To provide multiple backgrounds and/or borders, the pseudo-elements are pushed behind the content layer and pinned to the desired points of the HTML element using absolute positioning.

The pseudo-elements contain no true content and are absolutely positioned. This means that they can be stretched to sit over any area of the “parent” element without affecting its content. This can be done using any combination of values for the top, right, bottom, left, width, and height properties and is the key to their flexibility.

What effects can be achieved?

Using just one element you can create parallax effects, multiple background colours, multiple background images, clipped background images, image replacement, expandable boxes using images for borders, fluid faux columns, images existing outside the box, the appearance of multiple borders, and other popular effects that usually require images and/or the use of presentational HTML. It is also possible to include 2 extra presentational images as generated content.

The Multiple Backgrounds with CSS 2.1 and Multiple Borders with CSS 2.1 demo pages show how several popular examples of these effects can be achieved with this technique.

Most structural elements will contain child elements. Therefore, more often than not, you will be able to gain a further 2 pseudo-elements to use in the presentation by generating them from the first child (and even last-child) element of the parent element. In addition, you can use style changes on :hover to produce complex interaction effects.

Example code: multiple background images

Using this technique it is possible to reproduce multiple-background parallax effects like those found on the Silverback site using just one HTML element.

The element gets its own background image and any desired padding. By relatively positioning the element it acts as the reference point when absolutely positioning the pseudo-elements. The positive z-index will allow for the correct z-axis positioning of the pseudo-elements.

#silverback {
  position: relative;
  z-index: 1;
  min-width: 200px;
  min-height: 200px;
  padding: 120px 200px 50px;
  background: #d3ff99 url(vines-back.png) -10% 0 repeat-x;
}

Both pseudo-elements are absolutely positioned and pinned to each side of the element. The z-index value of -1 moves the pseudo-elements behind the content layer. This way the pseudo-elements sit on top of the element’s background and border but all the content is still selectable or clickable.

#silverback:before,
#silverback:after {
  position: absolute;
  z-index: -1;
  top: 0;
  left: 0;
  right: 0;
  bottom: 0;
  padding-top: 100px;
}

Each pseudo-element then has a repeated background-image set. This is all that is needed to reproduce the parallax effect.

The content property lets you add an image as generated content. With two pseudo-elements you can add 2 further images to an element. They can be crudely positioned within the pseudo-element box by varying other properties such as text-align and padding.

#silverback:before {
  content: url(gorilla-1.png);
  padding-left: 3%;
  text-align: left;
  background: transparent url(vines-mid.png) 300% 0 repeat-x;
}

#silverback:after {
  content: url(gorilla-2.png);
  padding-right: 3%;
  text-align: right;
  background: transparent url(vines-front.png) 70% 0 repeat-x;
}

The finished product is part of the Multiple Backgrounds with CSS 2.1 demo.

Example code: fluid faux columns

Another application is creating equal height fluid columns without images or extra nested containers.

The HTML base is very simple. I’ve used specific classes on each child div rather than relying on CSS 2.1 selectors that IE6 does not support. If you don’t require IE6 support you don’t actually need the classes.

<div id="faux">
  <div class="main">[content]</div>
  <div class="supp1">[content]</div>
  <div class="supp2">[content]</div>
</div>

The percentage-width container is once again relatively positioned and a positive z-index is set. Applying overflow:hidden gets the element to wrap its floated children and will hide the overflowing pseudo-elements. The background colour will provide the colour for one of the columns.

#faux {
  position: relative;
  z-index: 1;
  width: 80%;
  margin: 0 auto;
  overflow: hidden;
  background: #ffaf00;
}

By using relative positioning on the child div‘s you can also control the order of the columns independently of their source order.

#faux div {
  position: relative;
  float: left;
  width: 30%;
}

#faux .main { left: 35%; }
#faux .supp1 { left: -28.5%; }
#faux .supp2 { left: 8.5%; }

The other two full-height columns are produced by creating, sizing, and positioning pseudo-elements with backgrounds. These backgrounds can be (repeating) images if the design requires.

#faux:before,
#faux:after {
   content: "";
   position: absolute;
   z-index: -1;
   top: 0;
   right: 0;
   bottom: 0;
   left: 33.333%;
   background: #f9b6ff;
}

#faux:after {
   left: 66.667%;
   background: #79daff;
}

The finished product is part of the Multiple Backgrounds with CSS 2.1 demo.

Example code: multiple borders

Multiple borders are produced in much the same way. Using them can avoid the need for images to produce simple effects.

An element must be relatively positioned and have sufficient padding to contain the width of the extra border you will be creating with pseudo-elements.

#borders {
   position: relative;
   z-index: 1;
   padding: 30px;
   border: 5px solid #f00;
   background: #ff9600;
}

The pseudo-elements are positioned at specific distances away from the edge of the element’s box, moved behind the content layer with the negative z-index, and given the border and background values you want.

#borders:before {
   content: "";
   position: absolute;
   z-index: -1;
   top: 5px;
   left: 5px;
   right: 5px;
   bottom: 5px;
   border: 5px solid #ffea00;
   background: #4aa929;
}

#borders:after {
   content: "";
   position: absolute;
   z-index: -1;
   top: 15px;
   left: 15px;
   right: 15px;
   bottom: 15px;
   border: 5px solid #00b4ff;
   background: #fff;
}

That’s all there is to it. The finished product is part of the Multiple Borders with CSS 2.1 demo.

Progressive enhancement and legacy browsers

IE6 and IE7 have no support for CSS 2.1 pseudo-elements and will ignore all :before and :after declarations. They get none of the enhancements but are left with the basic usable experience.

A warning about Firefox 3.0

Firefox 3.0 supports CSS 2.1 pseudo-elements but does not support their positioning. Due to this partial support, you should avoid declaring display:block for absolutely positioned pseudo-elements that explicitly declare a width or height values. However, when using borders there is no graceful fallback for Firefox 3.0. Although, sometimes an improved appearance in Firefox 3.0 can be achieved by adding display:block to pseudo-element hacks that use borders.

Enhancing with CSS3

All the applications included in this article could be further enhanced to take advantage of present-day CSS3 implementations.

Using border-radius, rgba, and transforms, and CSS3 multiple background images in tandem with pseudo-elements can produce even more complex presentations that I hope to include in a future article. Currently there is no browser support for the use of CSS3 transitions or animations on pseudo-elements.

In the future: CSS3 pseudo-elements

The proposed extensions to pseudo-elements in the CSS3 Generated and Replaced Content Module include the addition of nested pseudo-elements (::before::before), multiple pseudo-elements (::after(2)), wrapping pseudo-elements (::outside), and the ability to insert pseudo-elements into later parts of the document (::alternate).

These changes would provide a near limitless number, and arrangement, of pseudo-elements for all sorts of complex effects and presentations using just one element.

Let me know what you’ve done

I’ve focused on just a few applications and popular effects. If you find other applications, limitations, or want to share how you’ve applied this technique please leave a comment below or let me know on Twitter (@necolas.

Translations

• 使用css2.1实现多重背景、多重边框效果

Using within-page links presses the jumped-to content right at the very top of the viewport. This can be a problem when using a fixed header. With a bit of hackery, there are some CSS methods to insert space between the top of the viewport and the target element within a page.

Demo: Jump links and viewport positioning

Known support: varies depending on method used.

This experiment is the result of a post Chris Coyier made on Forrst. Chris’ method was to add an empty span element to the target element, shift the id attribute onto the span, and then absolutely position the span somewhere above it’s parent element.

That method works but it requires changes to the HTML. The comments on Chris’ post suggested the use of psuedo-elements or padding. This experiment expands on, and combines, some of those suggestions to show the limitations of each method and document their browser support.

Simplest method

If you need to jump to an element with simple styling then using the :before pseudo-element is a quick and simple approach.

#target:before {
   content: "";
   display: block;
   height: 50px;
   margin: -30px 0 0;
}

The drawbacks are that it requires browser support for pseudo-elements and it will fail if the target element has a background colour, a repeated background image, padding-top, or border-top as part of its rule set.

More robust method

The more robust method uses a transparent border, negative margin, and the background-clip property. If a top border is required then it can be mimicked using a pseudo-element, as described in Multiple Backgrounds and Borders with CSS 2.1.

#target {
   position: relative;
   border-top: 52px solid transparent;
   margin: -30px 0 0;
   -webkit-background-clip: padding-box;
   -moz-background-clip: padding;
   background-clip: padding-box;
}

#target:before {
   content: "";
   position: absolute;
   top: -2px;
   left: 0;
   right: 0;
   border-top: 2px solid #ccc;
}

There are still drawbacks: it requires browser support for background-clip if there is a background color, gradient, or repeating image set on the target element; it requires browser support for pseudo-elements and their positioning if a top border is desired; and it interferes with the standard use of margins.

To see these methods in action – as well as more details on the code, browser support, and drawbacks – have a look at the demo page. Please let me know if you know of better techniques.

Taking a “mobile first” approach to web development poses some challenges if you need to provide a “desktop” experience for legacy versions of IE. Using a CSS pre-processor like Sass can help.

As of Sass 3.2, there is another way of catering for IE, described by Jake Archibald.

One aspect of a “mobile first” approach to development is that your styles are usually gradually built up from a simple base. Each new “layer” of CSS adds presentational adjustments and complexity, via CSS3 Media Queries, to react to and make use of additional viewport space. However, IE 6/7/8 do not support CSS3 Media Queries. If you want to serve IE 6/7/8 something more than just the base CSS, then you need a solution that exposes the “enhancing” CSS to those browsers.

Popular existing options

An existing option is the use of a CSS3 Media Query polyfill, such as Respond.js. However, there are some drawbacks to this approach (see the project README), such as the introduction of a JavaScript dependency and the XHRing of your style sheets, which may introduce performance or cross-domain security issues. Furthermore, adding support for CSS3 Media Queries is probably not necessary for these legacy browsers. The main concern is exposing the “enhancing” CSS.

Another method, which Jeremy Keith has described in his post on Windows mobile media queries, is to use separate CSS files: one basic global file, and an “enhancing” file that is referenced twice in the <head> of the document. The “enhancing” file is referenced once using a media attribute containing a CSS3 Media Query value. This prevents it being downloaded by browsers (such as IE 6/7/8) which do not support CSS3 Media Queries. The same file is then referenced again, this time wrapped in an IE conditional comment (without the use of a CSS3 Media Query value) to hide it from modern browsers. However, this approach becomes somewhat cumbersome, and introduces multiple HTTP requests, if you have multiple breakpoints in your responsive design.

Getting Sass to help

Sass 3.1 provides some features that help make this second approach more flexible. The general advantages of the Sass-based approach I’ve used are:

1. You have full control over how your style sheets are broken up and reassembled.
2. It removes the performance concerns of having to reference several separate style sheets for each breakpoint in the responsive design, simply to cater for IE 6/7/8.
3. You can easily repeat large chunks of CSS in separate compiled files without introducing maintenance problems.

The basic idea is to produce two versions of your compiled CSS from the same core code. One version of your CSS includes CSS3 @media queries and is downloaded by modern browsers. The other version is only downloaded by IE 6/7/8 in a desktop environment and contains no CSS3 @media queries.

To do this, you take advantage of the fact that Sass can import and compile separate .scss/.sass files into a single CSS file. This allows you to keep the CSS rules used at any breakpoint completely separate from the @media query that you might want it to be a part of.

This is not a CSS3 Media Query polyfill, so one assumption is that IE 6/7/8 users will predominantly be using mid-size screens and should receive styles appropriate to that environment. Therefore, in the example below, I am making a subjective judgement by including all the breakpoint styles up to a width of 960px but withholding those for any breakpoints beyond that.

The ie.scss file imports numerous other files, each containing a layer of CSS that builds upon the previous each layer of CSS. No CSS3 @media queries are contained within the files or the ie.scss file. It then compiles to a single CSS file that is designed to be served only to IE 6/7/8.

// ie.scss

@import "base";
@import "320-up";
@import "480-up";
@import "780-up";
@import "960-up";

The style.scss file imports the code for each breakpoint involved in the design (including any beyond the limit imposed for legacy versions of IE) but nests them within the relevant CSS3 @media query. The compiled version of this file is served to all browsers apart from IE 6/7/8 and IEMobile.

// style.scss

@import "base";
@media (min-width:320px) {
    @import "320-up"; }
@media (min-width:480px) {
    @import "480-up"; }
@media (min-width:780px) {
    @import "780-up"; }
@media (min-width:960px) {
    @import "960-up"; }
@media (min-width:1100px) {
    @import "1100-up"; }

The resulting CSS files can then be referenced in the HTML. It is important to hide the ie.css file from any IE-based mobile browsers. This ensures that they do not download the CSS meant for desktop versions of IE.

<!--[if (gt IE 8) | (IEMobile)]><!-->
<link rel="stylesheet" href="/css/style.css">
<!--<![endif]-->

<!--[if (lt IE 9) & (!IEMobile)]>
<link rel="stylesheet" href="/css/ie.css">
<![endif]-->

This Sass-enabled approach works just as well if you need to serve a basic style sheet for mobiles without CSS3 Media Query support, and prevent those devices from downloading the CSS used to adapt the layout to wider viewports. For example, you can avoid importing base.scss into the ie.scss and style.scss files. It can then be referenced separately in the HTML.

<link rel="stylesheet" href="/css/base.css">
<link rel="stylesheet" href="/css/style.css" media="(min-width:320px)">

<!--[if (lt IE 9) & (!IEMobile)]>
<link rel="stylesheet" href="/css/ie.css">
<![endif]-->

You’ll notice that I didn’t wrap the style.css reference in a conditional comment to hide it from legacy versions of IE. It’s not necessary this time because the value of the media attribute is not understood by legacy versions of IE, and the style sheet will not be downloaded.

In different circumstances, different combinations of style sheets and media attribute values will be more appropriate.

Summary

Even if you want to don’t want to use any of the Sass or SCSS syntax, the pre-processor itself can help you to write your CSS in a “mobile first” manner (with multiple breakpoints), provide a “desktop” experience for IE 6/7/8, and avoid some of the performance or maintenance concerns that are sometimes present when juggling the two requirements.

I’m relatively new to using Sass, so there may be even better ways to achieve the same result or even to prevent the inclusion of IE-specific CSS unless the file is being compiled into a style sheet that only IE will download.

What is the cascade?

The cascade is a mechanism for determining which styles should be applied to a given element, based on the rules that have cascaded down from various sources.

The cascade takes importance, origin, specificity, and source order of style rules into account. It assigns a weight to each rule. When multiple rules apply to a given element, the rule with the greatest weight takes precedence. The result is an unambiguous way to determine the value of a given element/property combination.

Browsers apply the following sorting logic:

• Find all declarations that apply to a given element/property combination, for the target media type.

• Sort declarations according to their importance (normal or important) and origin (author, user, or user agent). From highest to lowest precedence:

  1. user !important declarations
     
  2. author !important declarations
     
  3. author normal declarations
     
  4. user normal declarations
     
  5. user agent declarations

• If declarations have the same importance and source, sort them by selector specificity.

• Finally, if declarations have the same importance, source, and specificity, sort them by the order they are specified in the CSS. The last declaration wins.

What is specificity?

Specificity is a method of conflict resolution within the cascade.

Specificity is calculated in a very particular way, based on the values of 4 distinct categories. For explanatory purposes, the CSS2 spec represents these categories using the letters a, b, c, and d. Each has a value of 0 by default.

• a is equal to 1 if the declaration comes from a style attribute in the HTML (“inline styles”) rather than a CSS rule with a selector.
• b is equal to the number of ID attributes in a selector.
• c is equal to the number of other attributes and pseudo-classes in a selector.
• d is equal to the number of elements and pseudo-elements in a selector.

The specificity is given by concatenating all 4 resulting numbers. More specific selectors take precedence over less specific ones.

For example, the selector #id .class[href] element:hover contains:

• 1 ID (b is 1)
• 1 class, 1 attribute selector, and 1 pseudo-class (c is 3)
• 1 element (d is 1)

Therefore, it has a specificity of 0,1,3,1. Note that a selector containing a single ID (0,1,0,0) will have a higher specificity than one containing any number of other attributes or elements (e.g., 0,0,10,20). This is one of the reasons why many modern CSS architectural patterns avoid using IDs for styling purposes.

What is inheritance?

Inheritance is distinct from the cascade and involves the DOM tree.

Inheritance is the process by which elements inherit the the values of properties from their ancestors in the DOM tree. Some properties, e.g. color, are automatically inherited by the children of the element to which they are applied. Each property defines whether it will be automatically inherited.

The inherit value can be set for any property and will force a given element to inherit its parent element’s property value, even if the property is not normally inherited.

About !important

The above should make it apparent that !important is a separate concept to specificity. It has no effect on the specificity of a rule’s selector.

An !important declaration has a greater precedence than a normal declaration (see the previously mentioned cascade sorting logic), even declarations contained in an element’s style attribute.

[CSS terminology reference]

Translations

• CSS: каскад, специфика и наследование

A collection of thoughts, experiences, ideas that I like, and ideas that I have been experimenting with over the last year. It covers HTML semantics, components and approaches to front-end architecture, class naming patterns, and HTTP compression.

About semantics

Semantics is the study of the relationships between signs and symbols and what they represent. In linguistics, this is primarily the study of the meaning of signs (such as words, phrases, or sounds) in language. In the context of front-end web development, semantics are largely concerned with the agreed meaning of HTML elements, attributes, and attribute values (including extensions like Microdata). These agreed semantics, which are usually formalised in specifications, can be used to help programmes (and subsequently humans) better understand aspects of the information on a website. However, even after formalisation, the semantics of elements, attributes, and attribute values are subject to adaptation and co-option by developers. This can lead to subsequent modifications of the formally agreed semantics (and is an HTML design principle).

Distinguishing between different types of HTML semantics

The principle of writing “semantic HTML” is one of the foundations of modern, professional front-end development. Most semantics are related to aspects of the nature of the existing or expected content (e.g. h1 element, lang attribute, email value of the type attribute, Microdata).

However, not all semantics need to be content-derived. Class names cannot be “unsemantic”. Whatever names are being used: they have meaning, they have purpose. Class name semantics can be different to those of HTML elements. We can leverage the agreed “global” semantics of HTML elements, certain HTML attributes, Microdata, etc., without confusing their purpose with those of the “local” website/application-specific semantics that are usually contained in the values of attributes like the class attribute.

Despite the HTML5 specification section on classes repeating the assumed “best practice” that…

…authors are encouraged to use [class attribute] values that describe the nature of the content, rather than values that describe the desired presentation of the content.

…there is no inherent reason to do this. In fact, it’s often a hindrance when working on large websites or applications.

• Content-layer semantics are already served by HTML elements and other attributes.
• Class names impart little or no useful semantic information to machines or human visitors unless it is part of a small set of agreed upon (and machine readable) names – Microformats.
• The primary purpose of a class name is to be a hook for CSS and JavaScript. If you don’t need to add presentation and behaviour to your web documents, then you probably don’t need classes in your HTML.
• Class names should communicate useful information to developers. It’s helpful to understand what a specific class name is going to do when you read a DOM snippet, especially in multi-developer teams where front-enders won’t be the only people working with HTML components.

Take this very simple example:

<div class="news">
    <h2>News</h2>
    [news content]
</div>

The class name news doesn’t tell you anything that is not already obvious from the content. It gives you no information about the architectural structure of the component, and it cannot be used with content that isn’t “news”. Tying your class name semantics tightly to the nature of the content has already reduced the ability of your architecture to scale or be easily put to use by other developers.

Content-independent class names

An alternative is to derive class name semantics from repeating structural and functional patterns in a design. The most reusable components are those with class names that are independent of the content.

We shouldn’t be afraid of making the connections between layers clear and explicit rather than having class names rigidly reflect specific content. Doing this doesn’t make classes “unsemantic”, it just means that their semantics are not derived from the content. We shouldn’t be afraid to include additional HTML elements if they help create more robust, flexible, and reusable components. Doing so does not make the HTML “unsemantic”, it just means that you use elements beyond the bare minimum needed to markup the content.

Front-end architecture

The aim of a component/template/object-oriented architecture is to be able to develop a limited number of reusable components that can contain a range of different content types. The important thing for class name semantics in non-trivial applications is that they be driven by pragmatism and best serve their primary purpose – providing meaningful, flexible, and reusable presentational/behavioural hooks for developers to use.

Reusable and combinable components

Scalable HTML/CSS must, by and large, rely on classes within the HTML to allow for the creation of reusable components. A flexible and reusable component is one which neither relies on existing within a certain part of the DOM tree, nor requires the use of specific element types. It should be able to adapt to different containers and be easily themed. If necessary, extra HTML elements (beyond those needed just to markup the content) and can be used to make the component more robust. A good example is what Nicole Sullivan calls the media object.

Components that can be easily combined benefit from the avoidance of type selectors in favour of classes. The following example prevents the easy combination of the btn component with the uilist component. The problems are that the specificity of .btn is less than that of .uilist a (which will override any shared properties), and the uilist component requires anchors as child nodes.

.btn { /* styles */ }
.uilist { /* styles */ }
.uilist a { /* styles */ }

<nav class="uilist">
    <a href="#">Home</a>
    <a href="#">About</a>
    <a class="btn" href="#">Login</a>
</nav>

An approach that improves the ease with which you can combine other components with uilist is to use classes to style the child DOM elements. Although this helps to reduce the specificity of the rule, the main benefit is that it gives you the option to apply the structural styles to any type of child node.

.btn { /* styles */ }
.uilist { /* styles */ }
.uilist-item { /* styles */ }

<nav class="uilist">
    <a class="uilist-item" href="#">Home</a>
    <a class="uilist-item" href="#">About</a>
    <span class="uilist-item">
        <a class="btn" href="#">Login</a>
    </span>
</nav>

JavaScript-specific classes

Using some form of JavaScript-specific classes can help to reduce the risk that thematic or structural changes to components will break any JavaScript that is also applied. An approach that I’ve found helpful is to use certain classes only for JavaScript hooks – js-* – and not to hang any presentation off them.

<a href="/login" class="btn btn-primary js-login"></a>

This way, you can reduce the chance that changing the structure or theme of components will inadvertently affect any required JavaScript behaviour and complex functionality.

Component modifiers

Components often have variants with slightly different presentations from the base component, e.g., a different coloured background or border. There are two mains patterns used to create these component variants. I’m going to call them the “single-class” and “multi-class” patterns.

The “single-class” pattern

.btn, .btn-primary { /* button template styles */ }
.btn-primary { /* styles specific to save button */ }

<button class="btn">Default</button>
<button class="btn-primary">Login</button>

The “multi-class” pattern

.btn { /* button template styles */ }
.btn-primary { /* styles specific to primary button */ }

<button class="btn">Default</button>
<button class="btn btn-primary">Login</button>

If you use a pre-processor, you might use Sass’s @extend functionality to reduce some of the maintenance work involved in using the “single-class” pattern. However, even with the help of a pre-processor, my preference is to use the “multi-class” pattern and add modifier classes in the HTML.

I’ve found it to be a more scalable pattern. For example, take the base btn component and add a further 5 types of button and 3 additional sizes. Using a “multi-class” pattern you end up with 9 classes that can be mixed-and-matched. Using a “single-class” pattern you end up with 24 classes.

It is also easier to make contextual tweaks to a component, if absolutely necessary. You might want to make small adjustments to any btn that appears within another component.

/* "multi-class" adjustment */
.thing .btn { /* adjustments */ }

/* "single-class" adjustment */
.thing .btn,
.thing .btn-primary,
.thing .btn-danger,
.thing .btn-etc { /* adjustments */ }

A “multi-class” pattern means you only need a single intra-component selector to target any type of btn-styled element within the component. A “single-class” pattern would mean that you may have to account for any possible button type, and adjust the selector whenever a new button variant is created.

Structured class names

When creating components – and “themes” that build upon them – some classes are used as component boundaries, some are used as component modifiers, and others are used to associate a collection of DOM nodes into a larger abstract presentational component.

It’s hard to deduce the relationship between btn (component), btn-primary (modifier), btn-group (component), and btn-group-item (component sub-object) because the names don’t clearly surface the purpose of the class. There is no consistent pattern.

In early 2011, I started experimenting with naming patterns that help me to more quickly understand the presentational relationship between nodes in a DOM snippet, rather than trying to piece together the site’s architecture by switching back-and-forth between HTML, CSS, and JS files. The notation in the gist is primarily influenced by the BEM system‘s approach to naming, but adapted into a form that I found easier to scan.

Since I first wrote this post, several other teams and frameworks have adopted this approach. MontageJS modified the notation into a different style, which I prefer and currently use in the SUIT framework:

/* Utility */
.u-utilityName {}

/* Component */
.ComponentName {}

/* Component modifier */
.ComponentName--modifierName {}

/* Component descendant */
.ComponentName-descendant {}

/* Component descendant modifier */
.ComponentName-descendant--modifierName {}

/* Component state (scoped to component) */
.ComponentName.is-stateOfComponent {}

This is merely a naming pattern that I’m finding helpful at the moment. It could take any form. But the benefit lies in removing the ambiguity of class names that rely only on (single) hyphens, or underscores, or camel case.

A note on raw file size and HTTP compression

Related to any discussion about modular/scalable CSS is a concern about file size and “bloat”. Nicole Sullivan’s talks often mention the file size savings (as well as maintenance improvements) that companies like Facebook experienced when adopting this kind of approach. Further to that, I thought I’d share my anecdotes about the effects of HTTP compression on pre-processor output and the extensive use of HTML classes.

When Twitter Bootstrap first came out, I rewrote the compiled CSS to better reflect how I would author it by hand and to compare the file sizes. After minifying both files, the hand-crafted CSS was about 10% smaller than the pre-processor output. But when both files were also gzipped, the pre-processor output was about 5% smaller than the hand-crafted CSS.

This highlights how important it is to compare the size of files after HTTP compression, because minified file sizes do not tell the whole story. It suggests that experienced CSS developers using pre-processors don’t need to be overly concerned about a certain degree of repetition in the compiled CSS because it can lend itself well to smaller file sizes after HTTP compression. The benefits of more maintainable “CSS” code via pre-processors should trump concerns about the aesthetics or size of the raw and minified output CSS.

In another experiment, I removed every class attribute from a 60KB HTML file pulled from a live site (already made up of many reusable components). Doing this reduced the file size to 25KB. When the original and stripped files were gzipped, their sizes were 7.6KB and 6KB respectively – a difference of 1.6KB. The actual file size consequences of liberal class use are rarely going to be worth stressing over.

How I learned to stop worrying…

The experience of many skilled developers, over many years, has led to a shift in how large-scale website and applications are developed. Despite this, for individuals weaned on an ideology where “semantic HTML” means using content-derived class names (and even then, only as a last resort), it usually requires you to work on a large application before you can become acutely aware of the impractical nature of that approach. You have to be prepared to disgard old ideas, look at alternatives, and even revisit ways that you may have previously dismissed.

Once you start writing non-trivial websites and applications that you and others must not only maintain but actively iterate upon, you quickly realise that despite your best efforts, your code starts to get harder and harder to maintain. It’s well worth taking the time to explore the work of some people who have proposed their own approaches to tackling these problems: Nicole’s blog and Object Oriented CSS project, Jonathan Snook’s Scalable Modular Architecture CSS, and the Block Element Modifier method that Yandex have developed.

When you choose to author HTML and CSS in a way that seeks to reduce the amount of time you spend writing and editing CSS, it involves accepting that you must instead spend more time changing HTML classes on elements if you want to change their styles. This turns out to be fairly practical, both for front-end and back-end developers – anyone can rearrange pre-built “lego blocks”; it turns out that no one can perform CSS-alchemy.

I’m working on a project at Twitter that uses React and webpack. After a few conversations with @sokra last year, this is the setup I put in place for testing React components (authored using JSX and ES6) using Karma.

Dependencies

You’ll need to install various packages. It looks like a lot of dependencies, but all the non-Karma packages will be necessary for general module bundling during development.

Full set of required packages:

• babel-core: to transform JSX and transpile ES6.
• babel-loader: webpack loader for Babel.
• karma: the test runner.
• karma-chai-plugins: assertion library (or your library of choice).
• karma-chrome-launcher: Chrome browser launcher.
• karma-cli: CLI tool for Karma.
• karma-mocha: adapter for the Mocha testing framework.
• karma-sourcemap-loader: sourcemap loader.
• karma-webpack: to use webpack with Karma.
• react
• webpack: module bundler

webpack entry file

If you use webpack-specific features in your modules (e.g., loaders, plugins) you will need to use webpack to build a test bundle. The fastest and simplest approach is to create a single, test-specific entry file.

Create a file named tests.bundle.js. Within this file, you create a webpack context to match all the files that conform to a naming pattern – in this case *.spec.js(x).

var context = require.context('.', true, /.+.spec.jsx?$/);
context.keys().forEach(context);
module.exports = context;

Next, you point Karma to this file.

Karma config

Karma is configured using a karma.conf.js file. The browsers, plugins, and frameworks are specified in the standard way.

Point Karma at the tests.bundle.js file, and run it through the relevant preprocessor plugins (see example below).

The karma-webpack plugin relies on 2 custom properties of the Karma config: webpack and webpackMiddleware. The value of the former must be a webpack config object.

module.exports = function (config) {
  config.set({
    browsers: [ 'Chrome' ],
    // karma only needs to know about the test bundle
    files: [
      'tests.bundle.js'
    ],
    frameworks: [ 'chai', 'mocha' ],
    plugins: [
      'karma-chrome-launcher',
      'karma-chai',
      'karma-mocha',
      'karma-sourcemap-loader',
      'karma-webpack',
    ],
    // run the bundle through the webpack and sourcemap plugins
    preprocessors: {
      'tests.bundle.js': [ 'webpack', 'sourcemap' ]
    },
    reporters: [ 'dots' ],
    singleRun: true,
    // webpack config object
    webpack: {
      devtool: 'inline-source-map',
      module: {
        loaders: [
          {
            exclude: /node_modules/,
            loader: 'babel-loader,
            test: /.jsx?$/
          }
        ],
      }
    },
    webpackMiddleware: {
      noInfo: true,
    }
  });
};

Rather than duplicating your webpack config, you can require it in the Karma config file and override the devtool value to get sourcemaps working.

var webpackConfig = require('./webpack.config');
webpackConfig.devtool = 'inline-source-map';

module.exports = function (config) {
  config.set({
    ...
    webpack: webpackConfig
  });
};

That’s all you need to do to configure Karma to use webpack to load your JSX, ES6 React components.

Twitter Lite uses Redux for state management and relies on code-splitting. However, Redux’s default API is not designed for applications that are incrementally-loaded during a user session.

This post describes how I added support for incrementally loading the Redux modules in Twitter Lite. It’s relatively straight-forward and proven in production over several years.

Redux modules

Redux modules comprise of a reducer, actions, action creators, and selectors. Organizing redux code into self-contained modules makes it possible to create APIs that don’t involve directly referencing the internal state of a reducer – this makes refactoring and testing a lot easier. (More about the concept of redux modules.)

Here’s an example of a small “redux module”.

// data/notifications/index.js

const initialState = [];
let notificationId = 0;

const createActionName = name => `app/notifications/${name}`;

// reducer
export default function reducer(state = initialState, action = {}) {
  switch (action.type) {
    case ADD_NOTIFICATION:
      return [...state, { ...action.payload, id: notificationId += 1 }];
    case REMOVE_NOTIFICATION:
      return state.slice(1);
    default:
      return state;
  }
}

// selectors
export const selectAllNotifications = state => state.notifications;
export const selectNextNotification = state => state.notifications[0];

// actions
export const ADD_NOTIFICATION = createActionName(ADD_NOTIFICATION);
export const REMOVE_NOTIFICATION = createActionName(REMOVE_NOTIFICATION);

// action creators
export const addNotification = payload => ({ payload, type: ADD_NOTIFICATION });
export const removeNotification = () => ({ type: REMOVE_NOTIFICATION });

This module can be used to add and select notifications. Here’s an example of how it can be used to provide props to a React component.

// components/NotificationView/connect.js

import { connect } from 'react-redux';
import { createStructuredSelector } from 'reselect';
import { removeNotification, selectNextNotification } from '../../data/notifications';

const mapStateToProps = createStructuredSelector({
  nextNotification: selectNextNotification
});
const mapDispatchToProps = { removeNotification };

export default connect(mapStateToProps, mapDispatchToProps);

// components/NotificationView/index.js

import connect from './connect';
export class NotificationView extends React.Component { /*...*/ }
export default connect(NotificationView);

This allows you to import specific modules that are responsible for modifying and querying specific parts of the overall state. This can be very useful when relying on code-splitting.

However, problems with this approach are evident once it comes to adding the reducer to a Redux store.

// data/createStore.js

import { combineReducers, createStore } from 'redux';
Import notifications from './notifications';

const initialState = /* from local storage or server */

const reducer = combineReducers({ notifications });
const store = createStore(reducer, initialState);

export default store;

You’ll notice that the notifications namespace is defined at the time the store is created, and not by the Redux module that defines the reducer. If the “notifications” reducer name is changed in createStore, all the selectors in the “notifications” Redux module no longer work. Worse, every Redux module needs to be imported in the createStore file before it can be added to the store’s reducer. This doesn’t scale and isn’t good for large apps that rely on code-splitting to incrementally load modules. A large app could have dozens of Redux modules, many of which are only used by a few components and unnecessary for initial render.

Both of these issues can be avoided by introducing a Redux reducer registry.

Redux reducer registry

The reducer registry enables Redux reducers to be added to the store’s reducer after the store has been created. This allows Redux modules to be loaded on-demand, without requiring all Redux modules to be bundled in the main chunk for the store to correctly initialize.

// data/reducerRegistry.js

export class ReducerRegistry {
  constructor() {
    this._emitChange = null;
    this._reducers = {};
  }

  getReducers() {
    return { ...this._reducers };
  }

  register(name, reducer) {
    this._reducers = { ...this._reducers, [name]: reducer };
    if (this._emitChange) {
      this._emitChange(this.getReducers());
    }
  }

  setChangeListener(listener) {
    this._emitChange = listener;
  }
}

const reducerRegistry = new ReducerRegistry();
export default reducerRegistry;

Each Redux module can now register itself and define its own reducer name.

// data/notifications/index.js

import reducerRegistry from '../reducerRegistry';

const initialState = [];
let notificationId = 0;

const reducerName = 'notifications';

const createActionName = name => `app/${reducerName}/${name}`;

// reducer
export default function reducer(state = initialState, action = {}) {
  switch (action.type) {
    case ADD_NOTIFICATION:
      return [...state, { ...action.payload, id: notificationId += 1 }];
    case REMOVE_NOTIFICATION:
      return state.slice(1);
    default:
      return state;
  }
}

reducerRegistry.register(reducerName, reducer);

// selectors
export const selectAllNotifications = state => state[reducerName];
export const selectNextNotification = state => state[reducerName][0];

// actions
export const ADD_NOTIFICATION = createActionName(ADD_NOTIFICATION);
export const REMOVE_NOTIFICATION = createActionName(REMOVE_NOTIFICATION);

// action creators
export const addNotification = payload => ({ payload, type: ADD_NOTIFICATION });
export const removeNotification = () => ({ type: REMOVE_NOTIFICATION });

Next, we need to replace the store’s combined reducer whenever a new reducer is registered (e.g., after loading an on-demand chunk). This is complicated slightly by the need to preserve initial state that may have been created by reducers that aren’t yet loaded on the client. By default, once an action is dispatched, Redux will throw away state that is not tied to a known reducer. To avoid that, reducer stubs are created to preserve the state.

// data/createStore.js

import { combineReducers, createStore } from 'redux';
import reducerRegistry from './reducerRegistry';

const initialState = /* from local storage or server */

// Preserve initial state for not-yet-loaded reducers
const combine = (reducers) => {
  const reducerNames = Object.keys(reducers);
  Object.keys(initialState).forEach(item => {
    if (reducerNames.indexOf(item) === -1) {
      reducers[item] = (state = null) => state;
    }
  });
  return combineReducers(reducers);
};

const reducer = combine(reducerRegistry.getReducers());
const store = createStore(reducer, initialState);

// Replace the store's reducer whenever a new reducer is registered.
reducerRegistry.setChangeListener(reducers => {
  store.replaceReducer(combine(reducers));
});

export default store;

Managing the Redux store’s reducer with a registry should help you better code-split your application and modularize your state management.

Of the 1,089 new cases, Mumbai accounted for 748, with a cumulative tally of 12,142. With 75 new cases, Pune district’s tally has risen to 2,537.