In the last few months there has been increased discussion about some of the new elements that have been introduced in the HTML5 draft specification. This entry is primarily a counter argument to some of the comments that I disagree with.

The most recent and high-profile comments in regard to parts of the HTML5 specification come from The HTML5 Super Friends in an article entitled Guide to HTML5 Hiccups. It lays out their concerns with the HTML5 draft specification as it stood at the time of its writing and I am largely going to focus on the issues they have discussed.

The article and section elements

The first argument that I disagree with is that the article and section elements are redundant and, therefore, that the article element should be dropped.

article and section are identical except that article allows a pubdate attribute. We would suggest that article be dropped and section be adapted to allow an optional pubdate attribute or, even better, more explicit metadata.

The article and section elements are not identical according the to HTML5 draft specification. Here is what it says about the section element as of 13 September 2009:

The section element represents a generic document or application section. A section, in this context, is a thematic grouping of content, typically with a heading, possibly with a footer.

Now contrast that with what it says about the the article element:

The article element represents a section of a page that consists of a composition that forms an independent part of a document, page, application, or site.

An article element is “independent” in the sense that its contents could stand alone, for example in syndication, or as a interchangeable component on a user-configurable portal page.

That is a clear distinction that resists the reading of article and section being “identical”. The article element has a specific purpose: to mark parts of a document that form an independent composition that may be appropriate for syndication. It is a special kind of sectioning element that performs an essential role that is lacking in the semantics of the generic section element. This generic element serves only to thematically group content. That grouping may occur at the document level, within an independent article, or within a footer.

The article element has unique semantics and practical use. There is a fundamental conceptual difference between stand-alone compositions and sections of compositions, documents, or pages and this difference should be recognised and catered for in the specification. Websites regularly employ microformats and you don’t have to look far to see independent compositions currently marked up with class="hentry" or find links to individual blog comments and twitter updates. There is clearly a need for an easy way to define independent compositions and that is met with the introduction of the article element in HTML5.

What may be needed is a stronger clarification and definition of the article element to minimise the potential for this distinction to be overlooked and to highlight the differences from a generic document section.

The hgroup element

The hgroup element is a relatively recent addition to the draft specification. It is defined as serving a fairly specific purpose:

The hgroup element represents the heading of a section. The element is used to group a set of h1–h6 elements when the heading has multiple levels, such as subheadings, alternative titles, or taglines.

The element works to associate headings together so that the highest ranked heading descendant (if present) of the hgroup element is used as its text in document outlines and summary. Other heading descendants are treated as subheadings and are left out of outlines.

The HTML5 Super Friends have this to say about the hgroup element:

We don’t see the added value of this element and would instead add a boolean attribute to the heading element which allows content authors to specify if that particular heading should be included in the outline.

Bruce Lawson has similar concerns and proposes another alternative – removing the need for a wrapping element and defining a new element specifically for marking up subtitles:

I agree that hgroup is clumsy and likely to be misused. Rather than wrap an h1 and its h2 subtitle in hgroup to keep the subtitle out of the outlining algorithm, I would prefer to use

<header>
<h1>My blog</h1>
<subtitle>My wit and wisdom</subtitle>
</header>

as I think that;s easier to understand than a heading-that’s-not-a-heading, and it removes a wrapping element.

I disagree with these criticisms of the hgroup element and consider the proposed alternatives to be more problematic, less intuitive, less flexible, and further removed from the way in which authors currently markup subheadings.

The way that many authors are currently marking up subheadings is by using headings of various ranks and in various orders depending on whether the subheading or qualifying heading needs to appear above or below the main page heading. A subheading is still, conceptually, a heading of sorts and it cannot be accurately marked up with a paragraph or any other currently available element.

Allowing the addition of a boolean attribute to heading elements has several problems.

1. A boolean attribute may be less intuitive for authors than the hgroup element. The hgroup element relies upon and produces an association between all the headings it contains. Since headings and subheadings occur together and derive their meaning from each other, it is semantic to wrap these headings in an element. We know that the highest ranked heading contains the string to be used in the outline and that the other headings serve as ranked subheadings to this primary heading. A boolean attribute is only associated with the element that it is a part of. We can create no association between the element and adjacent elements. This is related to the next issue.

2. The hgroup itself acts as heading content while a boolean attribute would act only to remove headings from the outline. The hgroup element only removes the descendant headings that are those not of the highest rank. The boolean attribute shifts the burden onto the author to decide which headings should be marked for removal from the outline, rather than providing an element to wrap a collection of headings without authors having to be concerned with (or aware of) issues of outlining.

What about Bruce Lawson’s idea for a subtitle element? I believe that, irrespective of the what this element were actually called, it suffers from similar problems to the idea of using a boolean attribute. There is nothing to prevent the use of a subtitle element away from a heading, it creates no association with other elements, and it does not allow for ranking of subheadings.

One of my key points in relation to criticism of the hgroup element is that subheadings draw their meaning from context. A subheading (as opposed to a section heading) is only a sub-heading if it is associated with a higher ranking heading. Remove the higher ranking heading and what was once a subheading is likely to be understood as a heading.

The strength of the hgroup element over the two alternative suggestions I have referenced is that it is the only proposal that defines a subheading as contextual. I think that it is the most intuitive proposal (although perhaps none of them are particularly inuitive) – the name of the element is self-descriptive and encapsulates the contextual relationship and adjacent positioning of its child elements — and matches most closely with the way that subheadings are currently marked up on many websites.

The aside element

The HTML5 Super Friends are of the opinion that the aside element is not worth including in the specification:

The use cases for aside are too limited to warrant its inclusion in the specification. We were also concerned about potentially duplicating content within an aside.

However, the specification itself provides some fairly compelling uses for the element:

The element can be used for typographical effects like pull quotes or sidebars, for advertising, for groups of nav elements, and for other content that is considered separate from the main content of the page.

Authors might use the aside element for their blogrolls, for marking up adverts ranging from google ads on blogs to large banners on enterprise websites, for expanding on themes within an article or providing an extended definition of a term, for pull quotes, and anything else “tangentially related to the content around the aside element, and which could be considered separate from that content”.

Most of these uses would not involve duplication of content. Using the aside element for pull quotes would produce some instances of content duplication. However, this is not really a problem for users who are used to content being duplicated in this way in newspapers and magazines. It would not take much for search engines to adapt to deal with short amounts of duplicate content contained within an aside either. While I appreciate the point about duplicate content I’m not yet convinced that it is actually problematic.

The legend element

The current specification defines the legend element as providing an explanatory caption for the contents of its parent element. The parent element may be a fieldset, figure or details element. However, Remy Sharp‘s article entitled legend not such a legend anymore shows why it is not practical to use legend for the new elements details and figure – because it is not backwards compatible with current browsers and effectively unusable outside of a fieldset because of the inability to style the element.

In this case, forging a new element is most appropriate rather than trying to use an element like label which will only create confusion with little advantage.

Summary

I have discussed my reasons for disagreeing with certain feedback on the HTML5 draft specification. I have yet to be convinced that the article, hgroup, or aside elements should be dropped from the specification because it seems to me that they have necessary uses and advantages over alternatives.

Over the weekend two new HTML5 elements – summary and figcaption – were added to the draft specification. The introduction of summary and figcaption marks the acceptance that new elements are needed to act as captions or legends for the details and figure elements. The addition of the figcaption element finally begins to clear up the difficulty in marking-up figure element captions and looks to cement the place of the figure element in the HTML5 specification. The summary element does much the same for the details element but the very nature of the details element itself means that its future is not yet clear.

The figcaption element

This new element acts as the optional caption or legend for any content contained within its parent figure element.

If there is no figcaption element within a figure element then there is no caption for the rest of its content. If there is a figcaption element then it must be the first or last child of the figure element and only the first figcaption element (should there be more than one child figcaption of the parent figure element) represents a caption.

The figure element is used to mark up any self-contained content that may be referenced from the main flow of a document but could also be removed from the primary content (for example, to an appendix) without affecting its flow. This makes it suitable for various types of content ranging from graphs and data tables to photographs and code blocks.

<p><a href="#fig-ftse">Figure 1</a> shows the extent of the collapse in the markets and how recovery has been slow.</p>

<figure id="fig-ftse">
  <figcaption>Figure 1. The value of the FTSE 100 Index from 1999&ndash;2009.</figcaption>
  <img src="ftse-100-index-graph.jpg" alt="The index hit a record high at the end of 1999 and experienced two significant drops in the following last decade.">
</figure>

<p>This latest financial crisis hasn't stopped Alex from writing music and his latest track is actually worth listening to.</p>

<figure>
  <audio src="what-am-i-doing.mp3" controls></audio>
  <figcaption><cite>What am I doing?</cite> by Alex Brown</figcaption>
</figure>

The creation of the figcaption element is an important step forward for the HTML5 draft specification as it finally provides a reliable means to markup the caption for content that is best marked up as a figure. Previous attempts to use the legend element, the caption element, and the dt and dd elements had failed due to a lack of backwards compatibility when it came to styling these elements with CSS.

The summary element

This new element represents a summary, caption, or legend for any content contained within its parent details element.

The summary element must be the first child of a details element and if there is no summary element present then the user agent should provide its own. The reason for this is because the details element has a specific function – to markup additional information and allow the user to toggle the visibility of the additional information. Although it is not specified in the specification, it is expected that the summary element will act as the control that toggles the open-closed status of the contents of the parent details element.

<details>
  <summary>Technical details.</summary>
  <dl>
    <dt>Bit rate:</dt> <dd>190KB/s</dd>
    <dt>Filename:</dt> <dd>drum-and-bass-mix.mp3</dd>
    <dt>Duration:</dt> <dd>01:02:34</dd>
    <dt>File size:</dt> <dd>78.9MB</dd>
  </dl>
</details>

The introduction of the summary element seems to secure the future of the details element and the new behaviour that it affords, for now. When user agents begin to add support for the details element you won’t need JavaScript, or even CSS, to have expanding or collapsing sections in an HTML document.

The future of the details element

There will continue to be some debate over the inclusion of behaviour in an HTML specification especially given the widespread use of JavaScript to provide the expand-collapse functionality that details describes.

The details element writes some quite significant behaviour into an HTML document and I can see it being abused to provide generic expand-collapse functionality throughout a document. It is also not entirely clear what purpose the details element actually serves other than being an attempt to bypass the need for JavaScript or CSS to expand or collapse sections of a document.

There has been a general softening of the rough distinction between content, presentation, and behaviour. JavaScript libraries are being used to patch holes in browser CSS and HTML5 support, the CSS3 modules introduce plenty of behaviour that was previously only possibly with JavaScript, and the HTML5 specification is also introducing functionality and behaviour that previously required the use of JavaScript.

The future survival of the details element, and the behaviour associated with it, may well depend on browser implementations and author applications over the coming months.

This is a quick experiment that reproduces an image from I Love Typography using semantic HTML, CSS 2.1, a little CSS3. Along the way, I learnt about a few modern browser bugs and inconsistencies.

• See the demo: CSS typography experiment.
• See the bugs: Some new CSS 2.1 and CSS3 bugs in modern browsers.

I came across an image on I Love Typography that I thought could be reproduced using only semantic HTML and CSS.

The idea was to reproduce the image from simple markup, and to rely as much as possible on what can be achieved with CSS.

This is the HTML I ended up using.

<p>I love <strong>typography</strong> <em>a lot</em></p>

This is the CSS that controls the presentation of that content.

body {
  padding: 0;
  margin: 0;
  font-family: Times New Roman, serif;
  background: #000;
}

p {
  position: relative;
  width: 1100px;
  padding: 100px 0 0;
  margin: 0 auto;
  font-size: 175px;
  font-weight: bold;
  line-height: 1.2;
  letter-spacing: -13px;
  color: #0caac7;
  transform: rotate(-20deg);
}

/* "i" */
p:first-letter {
  float: left;
  margin: -137px -20px 0 0;
  font-size: 880px;
  line-height: 595px;
  text-transform: lowercase;
}

/* "love" */
p:first-line {
  font-size: 200px;
}

/* "typography" */
p strong {
  display: block;
  margin: -80px 0 0;
  font-weight: normal;
  letter-spacing: -2px;
  text-transform: capitalize;
}

p strong:first-letter {
  margin-right: -30px;
  color: #fff;
}

/* "a lot" */
p em {
  position: absolute;
  z-index: 10;
  top: 100px;
  left: 147px;
  width: 136px;
  overflow: hidden;
  padding-left: 64px;
  font-size: 200px;
  font-style: normal;
  text-transform: lowercase;
  color: #fff;
}

p em:first-letter {
  float: left;
  margin: 130px 0 0 -55px;
  font-size: 80px;
  font-style: italic;
  line-height: 20px;
  color: #fff;
}

/* create the heart shape */
p:before,
p:after {
  content: "";
  position: absolute;
  z-index: 1;
  top: 225px;
  left: 120px;
  width: 75px;
  height: 50px;
  background: #000;
  transform: rotate(45deg);
  border-radius: 25px 0 0 30px;
}

p:after {
  left: 138px;
  transform: rotate(-45deg);
  border-radius: 0 25px 30px 0;
}

/* hide the tip of the "t" from "a lot" */
p strong:before {
  content: "";
  position: absolute;
  z-index: 11;
  top: 205px;
  left: 341px;
  width: 7px;
  height: 7px;
  background: #000;
  border-radius: 7px;
}

The final CSS typography experiment approximates the original image in all modern browsers that support the CSS3 properties of border-radius and transform.

Some browsers render type (especially after rotational transformations) better than others. Note that all the screenshots are taken from browsers running on Windows Vista OS.

Browser bugs and inconsistencies

I’ve put together a small test page to highlight some new CSS 2.1 and CSS3 bugs in modern browsers. It includes two new CSS 2.1 bugs in Internet Explorer 8.

Here are two ways to include HTML5 elements in your WordPress post content without WordPress’ wpautop function wrapping them in p tags or littering your code with line breaks.

HTML5 has several new elements that you may want to use in your post content to markup document sections, headers, footers, pullquotes, figures, or groups of headings. One way to safely include these elements in your posts is simple; the other way is a bit more complicated. Both ways rely on hand-coding the HTML5 markup in the WordPress editor’s HTML view.

If you are adding HTML5 elements to your post content then you should use an HTML5 doctype.

Disable wpautop for your theme

This is the simple way. Disable the wpautop function so that WordPress makes no attempt to correct your markup and leaves you to hand-code every line of your posts. If you want total control over every line of your HTML then this is the option for you.

To disable wpautop entirely add these lines to your theme’s functions.php:

remove_filter('the_excerpt', 'wpautop');
remove_filter('the_content', 'wpautop');

However, wpautop is generally quite useful if most of your posts are simple text content and you only occasionally want to include HTML5 elements. Therefore, modifying wpautop to recognise HTML5 elements might be more practical.

Modify wpautop to recognise HTML5 elements

WordPress’ wpautop is part of the core functions and can be found in this file within your WordPress installation: wp-includes/formatting.php. It controls how and where paragraphs and line breaks are inserted in excerpts and post content.

In order to create a modified version of WordPress’ core wpautop function I started off by duplicating it in my theme’s functions.php file.

What I’ve experimented with is disabling wpautop and adding a modified copy of it – which includes HTML5 elements in its arrayss – to my theme’s functions.php file.

Add the following to your theme’s functions.php file and you’ll be able to use section, article, aside, header, footer, hgroup, figure, details, figcaption, and summary in your post content. (Probably best to try this in a testing environment first!)

/* -----------------------------
MODIFIED WPAUTOP - Allow HTML5 block elements in wordpress posts
----------------------------- */

function html5autop($pee, $br = 1) {
   if ( trim($pee) === '' )
      return '';
   $pee = $pee . "
"; // just to make things a little easier, pad the end
   $pee = preg_replace('|<br />s*<br />|', "

", $pee);
   // Space things out a little
    // *insertion* of section|article|aside|header|footer|hgroup|figure|details|figcaption|summary
   $allblocks = '(?:table|thead|tfoot|caption|col|colgroup|tbody|tr|td|th|div|dl|dd|dt|ul|ol|li|pre|select|form|map|area|blockquote|address|math|style|input|p|h[1-6]|hr|fieldset|legend|section|article|aside|header|footer|hgroup|figure|details|figcaption|summary)';
   $pee = preg_replace('!(<' . $allblocks . '[^>]*>)!', "
$1", $pee);
   $pee = preg_replace('!(</' . $allblocks . '>)!', "$1

", $pee);
   $pee = str_replace(array("
", "
"), "
", $pee); // cross-platform newlines
   if ( strpos($pee, '<object') !== false ) {
      $pee = preg_replace('|s*<param([^>]*)>s*|', "<param$1>", $pee); // no pee inside object/embed
      $pee = preg_replace('|s*</embed>s*|', '</embed>', $pee);
   }
   $pee = preg_replace("/

+/", "

", $pee); // take care of duplicates
// make paragraphs, including one at the end
   $pees = preg_split('/
s*
/', $pee, -1, PREG_SPLIT_NO_EMPTY);
   $pee = '';
   foreach ( $pees as $tinkle )
      $pee .= '<p>' . trim($tinkle, "
") . "</p>
";
   $pee = preg_replace('|<p>s*</p>|', '', $pee); // under certain strange conditions it could create a P of entirely whitespace
// *insertion* of section|article|aside
   $pee = preg_replace('!<p>([^<]+)</(div|address|form|section|article|aside)>!', "<p>$1</p></$2>", $pee);
   $pee = preg_replace('!<p>s*(</?' . $allblocks . '[^>]*>)s*</p>!', "$1", $pee); // don't pee all over a tag
   $pee = preg_replace("|<p>(<li.+?)</p>|", "$1", $pee); // problem with nested lists
   $pee = preg_replace('|<p><blockquote([^>]*)>|i', "<blockquote$1><p>", $pee);
   $pee = str_replace('</blockquote></p>', '</p></blockquote>', $pee);
   $pee = preg_replace('!<p>s*(</?' . $allblocks . '[^>]*>)!', "$1", $pee);
   $pee = preg_replace('!(</?' . $allblocks . '[^>]*>)s*</p>!', "$1", $pee);
   if ($br) {
      $pee = preg_replace_callback('/<(script|style).*?</\1>/s', create_function('$matches', 'return str_replace("
", "<WPPreserveNewline />", $matches[0]);'), $pee);
      $pee = preg_replace('|(?<!<br />)s*
|', "<br />
", $pee); // optionally make line breaks
      $pee = str_replace('<WPPreserveNewline />', "
", $pee);
   }
   $pee = preg_replace('!(</?' . $allblocks . '[^>]*>)s*<br />!', "$1", $pee);
// *insertion* of img|figcaption|summary
   $pee = preg_replace('!<br />(s*</?(?:p|li|div|dl|dd|dt|th|pre|td|ul|ol|img|figcaption|summary)[^>]*>)!', '$1', $pee);
   if (strpos($pee, '<pre') !== false)
      $pee = preg_replace_callback('!(<pre[^>]*>)(.*?)</pre>!is', 'clean_pre', $pee );
   $pee = preg_replace( "|
</p>$|", '</p>', $pee );

   return $pee;
}

// remove the original wpautop function
remove_filter('the_excerpt', 'wpautop');
remove_filter('the_content', 'wpautop');

// add our new html5autop function
add_filter('the_excerpt', 'html5autop');
add_filter('the_content', 'html5autop');

The results are not absolutely perfect but then neither is the original wpautop function. Certain ways of formatting the code will result in unwanted trailing </p> tags or a missing opening <p> tags.

For example, to insert a figure with caption into a post you should avoid adding the figcaption on a new line because an image or link appearing before the figcaption will end up with a trailing </p>.

<!-- this turns out ok -->
<figure>
  <a href="#"><img src="image.jpg" alt="" /></a><figcaption>A figure caption for your reading pleasure</figcaption>
</figure>

<!-- this turns out not so ok -->
<figure>
  <a href="#"><img src="image.jpg" alt="" /></a>
  <figcaption>A figure caption for your reading pleasure</figcaption>
</figure>

Another example would be when beginning the contents of an aside with a paragraph. You’ll have to leave a blank line between the opening aside tag and the first paragraph.

<aside>

This content could be a pullquote or information that is tangentially related to the surrounding content. But to get it wrapped in a paragraph you have to leave those blank lines either side of it before the tags.

</aside>

Room for improvement

Obviously there are still a few issues with this because if you format your post content in certain ways then you can end up with invalid HTML, even if it doesn’t actually affect the rendering of the page. But it seems to be pretty close!

Leave a comment or email me if you are using this function and find there that are instances where it breaks down. I ran numerous tests and formatting variations to try and iron out as many problems as possible but it’s unlikely that I tried or spotted everything.

Hopefully someone with more PHP and WordPress experience will be able to improve upon what I’ve been experimenting with, or find a simpler and more elegant solution that retains the useful wpautop functionality while allowing for the use of HTML5 elements in posts. Please share anything you find!

This toad jumped out of the long grass near a pond and kindly let me take a few photographs of it.

This is a remix of another author’s idea of using CSS to make a classic model of our solar system. Here, I’ve relied on CSS pseudo-elements and generated content to render scale models of the solar system from simple markup of the raw information.

There are three demos for this experiment, which is based on Alex Giron’s original Our Solar System in CSS3.

• Basic demo: Reworking of original experiment
• Advanced demo: Scale model of the Solar System
• Advanced demo (keyboard support): Scale model of the Solar System

The basic demo uses only CSS and simple, semantic HTML to relatively faithfully reproduce Alex’s original result.

The advanced demo is a rough scale model of the Solar System. It uses the same HTML as the “basic demo” but makes extensive use of CSS pseudo-elements, generated content, and various bits of CSS3.

The advanced demo (keyboard support) is an attempt to provide keyboard support by introducing slight modifications to the HTML. I’ve commented out the animations in this version of the demo.

Why rework the original experiment?

I was curious to see if the same result could be achieved with simpler HTML, by relying on some newer CSS features.

I experimented a bit further with generated content, shadows, and the way the layout of the solar system is implemented. Doing this exposed me to some of the different ways modern browsers are implementing CSS3. I’ve described some of those differences and bugs below.

A scale model of the solar system

The main demo is a scale model of the solar system. It uses 3 different scales: one for the object diameters; one for the distance of the planets from the sun; and one for the orbital period of each planet.

Semantic HTML and Microdata

The HTML is a list where each list item contains a title and description. I’ve included some HTML Microdata to provide hooks for generated content.

<li id="earth" itemscope>
  <h2 itemprop="object">Earth
  <dl>
    <dt>Description</dt>
    <dd itemprop="description">Earth is an ocean planet. Our home world's abundance of water - and life - makes it unique in our solar system. Other planets, plus a few moons, have ice, atmospheres, seasons and even weather, but only on Earth does the whole complicated mix come together in a way that encourages life - and lots of it.</dd>
    <dt>Diameter</dt>
    <dd itemprop="diameter">12,755 <abbr title="kilometers">km</abbr></dd>
    <dt>Distance from sun</dt>
    <dd itemprop="distance">150×10<sup>6</sup> <abbr title="kilometers">km</abbr></dd>
    <dt>Orbital period</dt>
    <dd itemprop="orbit">365<abbr title="days">d</abbr></dd>
  </dl>
</li>

CSS pseudo-elements and generated content

Pseudo-elements are used to produce the planets, Saturn’s ring, the planet names, and to add the scale information.

Given that the scales only make sense when CSS is loaded it isn’t appropriate to have the scales described in the HTML. Both demos use the same HTML but only one of them is a rough scale model. Therefore, in the scale model demo I’ve used generated content to present the ratios and append extra information to the headings.

header h1:after {content:": A scale model";}
header h2:after {content:"Planet diameters 1px : 1,220 km / Distance from sun 1px : 7,125,000 km / Orbital period 1s : 4d";}

#earth dd[itemprop=diameter]:after {content:" (5px) / ";}
#earth dd[itemprop=distance]:after {content:" (22px) / ";}
#earth dd[itemprop=orbit]:after {content:" (91s)";}

Even more complex 3D presentations are likely to be possible using webkit-perspective and other 3D transforms.

Keyboard support

With a little modification it is possible to provide some form of keyboard support so that the additional information and highlighting can be viewed without using a mouse. Doing so requires adding block-level anchors (allowed in HTML5) and modifying some of the CSS selectors.

Modern browser CSS3 inconsistencies

This experiment only works adequately in modern browsers such as Safari 4+, Chrome 4+, Firefox 3.6+ and Opera 10.5+.

Even among the current crop of modern browsers, there are bugs and varying levels of support for different CSS properties and values. In particular, webkit’s box-shadow implementation has issues.

There are a few other unusual :hover bugs in Opera 10.5 (most obvious in the basic demo). It should also be noted that the :hover area remains square in all modern browsers even when you apply a border-radius to the element.

Border radius

There are also a few other peculiarities around percentage units for border radius. Of the modern browsers, a square object with a border-radius of 50% will only produce a circle in Safari 5, Chrome 5, and Firefox 3.6.

Safari 4 doesn’t appear to support percentage units for border radius at all (which is why the CSS in the demos explicitly sets a -webkit-border-radius value for each object). Safari 5 and Chrome 5 do support percentage units for this property. However, Chrome 5 has difficulty rendering a 1px wide border on a large circle. Most of the border simply isn’t rendered.

In Opera 10.5, if you set border-radius to 50% you don’t always get a circle, so I have had to redeclare the border-radius for each object in pixel units.

It appears that this is one aspect of Opera’s non-prefixed border-radius implementation that is incorrect and in need of fixing.

Box shadow

Safari 4’s inferior box-shadow implementation means that inset shadows are not rendered on the planet bodies. In addition, the second box-shadow applied to Saturn (used to separate the planet from its ring) is completely missing in Safari 4 as it does not support a spread radius value.

Safari 5 and Chrome 5 are better but still problematic. The second box-shadow is not perfectly round as the box-shadow seems to use the pseudo-element’s computed border-radius. Furthermore, Chrome 5 on Windows does not properly support inset box-shadow meaning that the shadow ignores the border-radius declaration and appears as a protruding square.

The use of box-shadow to separate Saturn from the ring isn’t strictly necessary. You can create the separated ring using a border but box-shadow cannot be applied in a way that casts it over a border. Another alternative would be to add a black border around the planet to give the illusion of space between itself and the ring, but all browsers display a few pixels of unwanted background colour all along the outer edge of the rounded border.

I wanted the ring to share the appearance of a shadow being cast on it. Opera 10.5 and Firefox 3.6 get it right. Both webkit browsers get it wrong.

An accessible image replacement method using pseudo-elements and generated-content. This method works with images and/or CSS off, with semi-transparent images, doesn’t hide text from screen-readers or search engines, and provides fallback for IE 6 and IE 7.

Known support: Firefox 1.5+, Safari 3+, Chrome 3+, Opera 9+, IE 8+

What’s wrong with current methods?

The two most widely used image replacement techniques are the Gilder/Levin Method and the Phark Method. Both have different flaws.

The Gilder/Levin Method requires the addition of presentational HTML (an empty span) and doesn’t work with transparent images as the default text shows through. The Phark Method uses a negative text-indent to hide the text and so it is not visible when CSS is on and images are off.

Resurrecting the NIR method

Using pseudo-elements and generated-content as an image replacement technique isn’t a new idea. It was proposed and demonstrated by Paul Nash back in 2006. This is the Nash Image Replacement method.

<h1 class="nir">[content]</h1>

.nir {
   height: 100px; /* height of replacement image */
   padding: 0;
   margin: 0;
   overflow: hidden;
}

.nir:before {
   content: url(image.gif);
   display: block;
}

The height value is equal to that of the replacement image. Setting overflow:hidden ensures that the original content is not visible on screen when the image is loaded. The replacement image is inserted as generated content in the :before pseudo-element which is set to behave like a block element in order to push the element’s original content down.

What about IE 6 and IE 7?

Neither browser supports :before; if you need to support them you’ll have to rely on the Phark method. This can be done using conditional comments or safe IE6/7 hacks to serve alternative styles to legacy versions of IE .

<!--[if lte IE 7]>
<style>
.nir {
   height: 100px;
   padding: 0;
   margin: 0;
   overflow: hidden;
   text-indent: -9000px;
   background: url(image.gif) no-repeat 0 0;
}
</style>
<![endif]-->

Using the NIR method allows you to keep your HTML semantic and deliver improved accessibility to users of modern browsers. The Phark Method can then be served to IE 6 and IE 7.

Improving the NIR method

The first problem with NIR is that if images are disabled all browsers leave whitespace above the element’s content. Opera 10.5 even displays the text string “image”! If the height of the element is small enough this whitespace causes the element’s content to overflow and be partially or completely hidden when images are disabled.

Another consideration is what happens if an image doesn’t exist or fails to load. Safari and Chrome will display a “missing image” icon that cannot be removed. Once again, this can cause the element’s content to overflow and become partially or completely hidden to users.

A more robust version of the NIR method is the following modification:

.nir {
   height: 100px; /* height of replacement image */
   width: 400px; /* width of replacement image */
   padding: 0;
   margin: 0;
   overflow: hidden;
}

.nir:before {
   content: url(image.gif);
   display: inline-block;
   font-size: 0;
   line-height: 0;
}

Setting font-size and line-height to 0 avoids the whitespace problems in all browsers. Setting the element’s width equal to that of the replacement image and getting the pseudo-element to act as an inline-block helps minimise the problems in webkit browsers should an image fail to load.

Ideally browsers would avoid displaying anything in a pseudo-element when its generated-content image fails to load. If that were the case, the original NIR method would be all that is needed.

What about using sprites?

One of the most common uses of image replacement is for navigation. This often involves using a large sprite with :hover and :active states as a background image. It turns out that using sprites is not a problem for modern browsers. When using the modified-NIR method the sprite is included as a generated-content image that is positioned using negative margins.

This is an example that rebuilds the right-hand category navigation from Web Designer Wall using a sprite and the modified-NIR method.

<ul id="nav">
  <li id="nav-item-1"><a href="#non">Tutorials</a></li>
  <li id="nav-item-2"><a href="#non">Trends</a></li>
  <li id="nav-item-3"><a href="#non">General</a></li>
</ul>

/* modified-NIR */

#nav a {
  display: block;
  width: 225px;
  height: 46px;
  overflow: hidden;
}

#nav a:before {
   content:url(sprite.png);
   display:-moz-inline-box; /* for Firefox 1.5 & 2 */
   display:inline-block;
   font-size:0;
   line-height:0;
}

/* repositioning the sprite */

#nav-item-1 a:hover:before,
#nav-item-1 a:focus:before,
#nav-item-1 a:active:before {margin:-46px 0 0;}

#nav-item-2 a:before        {margin:-92px 0 0;}
#nav-item-2 a:hover:before,
#nav-item-2 a:focus:before,
#nav-item-2 a:active:before {margin:-138px 0 0;}

#nav-item-3 a:before        {margin:-184px 0 0;}
#nav-item-3 a:hover:before,
#nav-item-3 a:focus:before,
#nav-item-3 a:active:before {margin:-230px 0 0;}

/* :hover hack for IE8 if no a:hover styles declared */
#nav a:hover {cursor:pointer;}

For some reason IE8 refuses to reposition the image when the mouse is over the link unless a style is declared for a:hover. In most cases you will have declared a:hover styles for the basic links on your webpage, and this is enough. But it is worth being aware of this IE8 behaviour.

The addition of display:-moz-inline-box; is required to reposition the sprite in versions of Firefox prior to Firefox 3.0. They are very rare browsers but I’ve included it in case that level of legacy support is needed.

If you want image replacement in IE 6 and IE 7 the following additional styles can be served to those browsers using conditional comments.

/* Phark IR method */

#nav a {
   text-indent: -9000px;
   background: url(sprite.png) no-repeat;
}

/* repositioning the sprite */

#nav-item-1 a:hover,
#nav-item-1 a:active { background-position: 0 -46px; }

#nav-item-2 a        { background-position: 0 -92px; }
#nav-item-2 a:hover,
#nav-item-2 a:hover  { background-position: 0 -138px; }

#nav-item-3 a        { background-position: 0 -184px; }
#nav-item-3 a:hover,
#nav-item-3 a:active { background-position: 0 -230px; }

/* hack for IE6 */
#nav a:hover { margin: 0; }

The changes are fairly simple. But IE 6 applies the margins declared for a:hover:before to a:hover and so they need to be reset in the styles served to IE 6.

See the modified-NIR (using sprites) demo.

Research into improving the cross-browser consistency of both the “clearfix” and “overflow:hidden” methods of containing floats. The aim is to work around several bugs in IE6 and IE7.

This article introduces a new hack (with caveats) that can benefit the “clearfix” methods and the new block formatting context (NBFC) methods (e.g. using overflow:hidden) of containing floats. It’s one outcome of a collaboration between Nicolas Gallagher (that’s me) and Jonathan Neal.

If you are not familiar with the history and underlying principles behind methods of containing floats, I recommend that you have a read of Easy clearing (2004), Everything you know about clearfix is wrong (2010), and Clearfix reloaded and overflow:hidden demystified (2010).

Consistent float containment methods

The code is show below and documented in this GitHub gist. Found an improvement or flaw? Please fork the gist or leave a comment.

Micro clearfix hack: Firefox 3.5+, Safari 4+, Chrome, Opera 9+, IE 6+

.cf {
  /* for IE 6/7 */
  *zoom: expression(this.runtimeStyle.zoom="1", this.appendChild(document.createElement("br")).style.cssText="clear:both;font:0/0 serif");
  /* non-JS fallback */
  *zoom: 1;
}

.cf:before,
.cf:after {
  content: "";
  display: table;
}

.cf:after {
  clear: both;
}

Overflow hack (NBFC): Firefox 2+, Safari 2+, Chrome, Opera 9+, IE 6+

.nbfc {
  overflow: hidden;
  /* for IE 6/7 */
  *zoom: expression(this.runtimeStyle.zoom="1", this.appendChild(document.createElement("br")).style.cssText="clear:both;font:0/0 serif");
  /* non-JS fallback */
  *zoom: 1;
}

The GitHub gist also contains another variant of the clearfix method for modern browsers (based on Thierry Koblentz’s work). It provides greater visual consistency (avoiding edge-case bugs) for even older versions of Firefox.

The only difference from existing float-containment methods is the inclusion of a CSS expression that inserts a clearing line-break in IE 6 and IE 7. Jonathan and I found that it helps to resolve some of the visual rendering differences that exist between these browsers and more modern ones. First I’ll explain what some of those differences are and when they occur.

Containing floats in IE 6/7

In IE 6 and IE 7, the most common and robust method of containing floats within an element is to give it “layout” (find out more: On having Layout). Triggering “layout” on an element in IE 6/7 creates a new block formatting context (NBFC). However, certain IE bugs mean that previous float containment methods don’t result in cross-browser consistency. Specifically, this is what to expect in IE 6/7 when creating a NBFC:

1. The top- and bottom-margins of non-floated child elements are contained within the ancestor element that has been given “layout”. (Also expected in other browsers when creating a NBFC)
2. The bottom-margins of any right-floated descendants are contained within the ancestor. (Also expected in other browsers when creating a NBFC)
3. The bottom-margins of any left-floated children are not contained within the ancestor. The margin has no effect on the height of the ancestor and is truncated, having no affect outside of the ancestor either. (IE 6/7 bug)
4. In IE 6, if the right edge of the margin-box of a left-floated child is within 2px of the left edge of the content-box of its NBFC ancestor, the float’s bottom margin reappears and is contained within the parent. (IE 6 bug)
5. Unwanted white-space can appear at the bottom of a float-container. (IE 6/7 bug)

There is a lack of consistency between IE 6/7 and other browsers, and between IE 6 and IE 7. Thanks to Matthew Lein for his comment that directed me to this IE 6/7 behaviour. It was also recently mentioned by “Suzy” in a comment on Perishable Press.

IE 6/7’s truncation of the bottom-margin of left-floats is not exposed in many of the test-cases used to demonstrate CSS float containment techniques. Using an IE-only CSS expression helps to correct this bug.

The CSS expression

Including the much maligned <br style="clear:both"> at the bottom of the float-container, as well as creating a NBFC, resolved all these inconsistencies in IE 6/7. Doing so prevents those browsers from collapsing (or truncating) top- and bottom-margins of descendant elements.

Jonathan suggested inserting the clearing line-break in IE 6/7 only, using CSS expressions applied to fictional CSS properties. The CSS expression is the result of many iterations, tests, and suggestions. It runs only once, the first time an element receives the associated classname.

*zoom: expression(this.runtimeStyle.zoom="1", this.appendChild(document.createElement("br")).style.cssText="clear:both;font:0/0 serif");

It is applied to zoom, which is already being used to help contain floats in IE 6/7, and the use of the runtimeStyle object ensures that the expression is replaced once it has been run. The addition of font:0/0 serif prevents the occasional appearance of white-space at the bottom of a float-container. And the * hack ensures that only IE 6 and IE 7 parse the rule.

It’s worth noting that IE 6 and IE 7 parse almost any string used as CSS property. An earlier iteration used the entirely fictitious properties “-ms-inject” or “-ie-x” property to exploit this IE behaviour.

*-ie-x: expression(this.x||(this.innerHTML+='<br style="clear:both;font:0/0">',this.x=1));

However, this expression is evaluated over and over again. Using runtimeStyle instead avoids this. Sergey Chikuyonok also pointed out that using innerHTML destroys existing HTML elements that may event handlers attached to them. By using document.createElement and appendChild you can insert the new element without removing all the events attached to other descendant elements.

Containing floats in more modern browsers

There are two popular methods to contain floats in modern browsers. Creating a new block formatting context (as is done in IE 6/7 when hasLayout is triggered) or using a variant of the “clearfix” hack.

Creating a NBFC results in an element containing any floated children, and will prevent top- and bottom-margin collapse of non-floated children. When combined with the enhanced IE 6/7 containment method, it results in consistent cross-browser float containment.

The other method, known as “clearfix”, traditionally used a single :after pseudo-element to clear floats in a similar fashion to a structural, clearing HTML line-break. However, to prevent the top-margins of non-floats from collapsing into the margins of their float-containing ancestor, you also need to use the :before pseudo-element. This is the approach taken in Thierry Koblentz’s “clearfix reloaded”. In contemporary browsers, the micro clearfix hack is also suitable.

The method presented in this article should help improve the results of cross-browser float containment, whether you predominantly use “clearfix” or the NBFC method. The specific limitations of both the “clearfix” and various NBFC methods (as outlined in Thierry’s articles) remain.

Problems

Using a CSS expression to change the DOM in IE 6/7 creates problems of its own. Obviously, the DOM in IE 6/7 is now different to the DOM in other browsers. This affects any JavaScript DOM manipulation that may depend on :last-child or appending new children.

This is still an experimental work-in-progress that is primarily research-driven rather than seeking to become a practical snippet of production code. Any feedback, further testing, and further experimentation from others would be much appreciated.

Thanks to these people for contributing improvements: Jonathan Neal, Mathias Bynens, Sergey Chikuyonok, and Thierry Koblentz.

CSS is a versatile style language that is most frequently used to control the look and formatting of an HTML document based on information in the document tree. But there are some common publishing effects – such as formatting the first line of a paragraph – that would not be possible if you were only able to style elements based on this information. Fortunately, CSS has pseudo-elements and pseudo-classes.

As their names imply, they are not part of the DOM in the way that ‘real’ HTML elements and classes are. Instead, they are CSS abstractions that provide additional, and otherwise inaccessible, information about the document.

This article will discuss the CSS pseudo-elements that are part of CSS 2.1 – :first-letter, :first-line, :before, and :after – and how the :before and :after pseudo-elements can be exploited to create some interesting effects, without compromising the simplicity of your HTML. But first, let’s look at each type of pseudo-element and how to use them in their basic form.

The :first-line and :first-letter pseudo-elements

The :first-line pseudo-element lets you apply styles to the first formatted line of a block container element (i.e., elements with their display property set to block, inline-block, list-item, table-caption, or table-cell). For example:

p:first-line { font-weight: bold; }

…will change the first line of every paragraph to bold. The :first-line pseudo-element can be treated as if it were an extra HTML inline element wrapping only the first line of text in the paragraph.

The :first-letter pseudo-element lets you apply styles to the first letter (and any preceding punctuation) of the first formatted line of a block container element. No other inline content (e.g. an image) can appear before the text. For example:

p:first-letter { float: left; font-size: 200%; }

…will produce a basic ‘drop cap’ effect. The first letter of every paragraph will be floated left, and twice as large as the other letters in the paragraph. The :first-letter pseudo-element can be treated as if it were an extra HTML inline element wrapping only the first letter of text in the paragraph.

The :first-line and :first-letter pseudo-elements can only be attached to block container elements, but the first formatted line can be contained within any block-level descendant (e.g., elements with their display property set to block or list-item) in the same flow (i.e., not floated or positioned). For example, the following HTML fragment and CSS:

<div><p>An example of the first line of text being within a descendant element</p></div>

div:first-line { font-weight: bold; }

…would still result in a bold first line of text, because the paragraph’s text is the first formatted line of the div.

The :before and :after pseudo-elements

The :before and :after pseudo-elements are used to insert generated content before or after an element’s content. They can be treated as if they were extra HTML inline elements inserted just before and after the content of their associated element.

Generated content is specified using the content property which, in CSS 2.1, can only be used in conjunction with the :before and :after pseudo-elements. Furthermore, you must declare the content property in order to generate the :before and :after pseudo-elements.

The content property can take string, url(), attr(), counter() and counters() values. The url() value is used to insert an image. The attr() function returns as a string the value of the specified attribute for the associated element. The counter() and counters() functions can be used to display the value of any CSS counters.

For example, the following HTML fragment and CSS:

<a href="http://wikipedia.org">Wikipedia</a>

a:after { content: " (" attr(href) ")"; }

…would display the value of the href attribute after a link’s content, resulting in the following anchor text for the example above: Wikipedia (http://wikipedia.org). This can be a helpful way to display the destination of specific links in printed web documents.

Keep in mind that CSS is meant for adding presentation and not content. Therefore, the content property should be used with caution.

It’s also worth noting that the :first-letter and :first-line pseudo-elements apply to the first letter and first line of an element including any generated content inserted using the :before and :after pseudo-elements.

Browser support for pseudo-elements

The :first-letter and :first-line pseudo-elements were introduced in CSS1 and there is wide basic support for them. However, IE 6 and IE 7 have particularly buggy implementations; even modern browsers are not entirely consistent in the way that they handle the :first-line and :first-letter pseudo-elements (example bugs).

The :before and :after pseudo-elements were introduced in the CSS 2.1 specification and are fully implemented in Firefox 3.5+, IE 8+, Safari 3+, Google Chrome, and Opera. Modern versions of Firefox even support CSS transitions and animations applied to pseudo-elements. However, legacy browsers like IE 6 and IE 7 do not support the :before and :after pseudo-elements at all.

For more detailed information on pseudo-element browser support, browser bugs, and workarounds, have a look at Sitepoint’s reference and this article on IE 6/7 issues.

In most cases, the :before and :after pseudo-elements can be used as part of a ‘progressive enhancement’ approach to design and development, because IE 6 and IE 7 will simply ignore them altogether. Alternatively, Modernizr now includes a robust feature test for generated content, providing one way to specify fallbacks or enhancements depending on browser support. The important thing is to remember to check what happens in browsers where support is missing.

Alternative ways to use pseudo-elements

Let’s take a look at how the :before and :after pseudo-elements can be used as the basis for some interesting effects. Most of the time, this involves generating empty :before and :after pseudo-elements by declaring an empty string as the value of the content property. They can then be manipulated as if they were empty inline HTML elements, keeping your HTML clean and giving you full control of certain effects from within CSS style sheets.

Simple visual enhancements, like speech bubbles and folded corners, can even be created without the need for images. This relies on the fact that you can create simple shapes using CSS.

Several types of ‘CSS polygons’ can be created as a result of browsers rendering borders at an angle when they meet. This can be exploited to create triangles. For example, the following HTML fragment and CSS:

<div class="triangle"></div>

.triangle {
  width: 0;
  height: 0;
  border-width: 20px;
  border-style: solid;
  border-color: red transparent transparent;
}

…will create a downward pointing, red triangle. By varying the width, height, border-width, border-style, and border-color values you can produce different shapes and control their orientation and colour. For more information, be sure to read Jon Rogan’s summary of the technique.

The more advanced pseudo-element hacks use the extra background canvas afforded by each :before and :after pseudo-element. This can help you crop background images, control the opacity of background images, and ‘fake’ multiple backgrounds and borders in browsers without support for CSS3 multiple backgrounds (e.g., IE 8). Taken to ludicrous extremes, you can even build a whole CSS icon set. To start with, let’s look at some simple effects that can be created without images or presentational HTML.

Creating CSS speech bubbles

In this example, a quote is styled to look like a speech bubble, using CSS. This is done by creating a triangle using a pseudo-element, and then absolutely positioning it in the desired place. By adding position:relative to the CSS styles for the HTML element, you can absolutely position the :after pseudo-element relative to its associated element.

<div class="quote">[Quoted text]</div>

.quote {
  position: relative;
  width: 300px;
  padding: 15px 25px 20px;
  margin: 20px auto;
  font: italic 26px/1.4 Georgia, serif;
  color: #fff;
  background: #245991;
}

.quote:after {
  content: "";
  position: absolute;
  top: 100%;
  right: 25px;
  border-width: 30px 30px 0 0;
  border-style: solid;
  border-color: #245991 transparent;
}

There’s nothing stopping you from adding some CSS3 to further enhance the effect for capable browsers. This could be adding rounded corners to the box or applying a skew transform to the triangle itself. Fiddle with the code in this example.

Creating CSS ‘ribbons’

Using the same principle, you can create a CSS ribbon effect without images or extra HTML. This time the effect uses 2 pseudo-element triangles. The HTML fragment is still very simple.

<div class="container">
    <h1>Simple CSS ribbon</h1>
    <p>[other content]</p>
</div>

You then need to use negative margins to pull the h1 outwards so that it extends over the padding and beyond the boundaries of the container div. The HTML fragment above can be styled using the following CSS:

.container {
  width: 400px;
  padding: 20px;
  margin: 20px auto;
  background: #fff;
}

.container h1 {
  position: relative;
  padding: 10px 30px;
  margin: 0 -30px 20px;
  font-size: 20px;
  line-height: 24px;
  font-weight: bold;
  color: #fff;
  background: #87A800;
}

From here, you only need to add the pseudo-element triangles to create the ‘wrapping’ appearance associated with ribbons. The :before and :after pseudo-elements share many styles, so you can simplify the code by only overriding the styles that differ between the two. In this case, the triangle created with the :after pseudo-element must appear on the opposite side of the heading, and will be a mirror image of the other triangle. So you need to override the shared styles that control its position and orientation.

.container h1:before,
.container h1:after {
  content: "";
  position: absolute;
  top: 100%;
  left: 0;
  border-width: 0 10px 10px 0;
  border-style: solid;
  border-color: transparent #647D01;
}

/* override shared styles */
.container h1:after {
  left: auto;
  right: 0;
  border-width: 0 0 10px 10px;
}

Fiddle with the code in this example.

Creating CSS folded corners

The final example of this form of pseudo-element hack creates a simple CSS folded-corner effect. A pseudo-element’s border properties are set to produce two differently-coloured touching triangles. One triangle is a slightly darker or lighter shade of the box’s background colour. The other triangle matches the background colour of the box’s parent (e.g. white). The pseudo-element is then positioned in the top right corner of its associated element to complete the effect.

.note {
  position: relative;
  padding: 20px;
  margin: 2em 0;
  color: #fff;
  background: #97C02F;
}

.note:before {
  content: "";
  position: absolute;
  top: 0;
  right: 0;
  border-width: 0 16px 16px 0;
  border-style: solid;
  border-color: #658E15 #fff;
}

Varying the size of the borders will vary the size and angle of the folded-corner. Fiddle with the code in this example.

Pseudo background-crop

Although creating polygons with pseudo-elements can produce some popular effects without images, the possibilities are inherently limited. But this is only one type of :before and :after pseudo-element hack. Treated as extra background canvases, they can be used to fill some gaps in existing browser support for CSS features.

One of those features is the cropping of background images. In the future, it’s likely that you’ll be able to crop background images using fragment identifiers, as is proposed in the CSS Image Values Module Level 3 draft. But at the moment no browsers support the use of fragment identifiers with bitmap images. Until they do, you can make use of this CSS 2.1 hack to emulate background image cropping in modern browsers.

The principle behind a ‘pseudo background-crop‘ is to apply a background-image to a pseudo-element rather than directly to an element in the HTML document. One of the applications of this technique is to crop icons that are part of a sprite.

For example, a web app might allow users to ‘save’, ‘edit’, or ‘delete’ an item. The HTML involved might look something like this:

<ul class="actions">
  <li class="save"><a href="#">Save</a></li>
  <li class="edit"><a href="#">Edit</a></li>
  <li class="delete"><a href="#">Delete</a></li>
</ul>

To enhance the appearance of these ‘action’ links, it is common to see icons sitting alongside the anchor text. For argument’s sake, let’s say that the relevant icons are part of a sprite that is organised using a 16px × 16px grid.

The :before pseudo-element – with dimensions that match the sprite’s grid unit – can be used to crop and display each icon. The sprite is referenced as a background image and the background-position property is used to control the precise positioning of each icon to be shown.

.actions a:before {
  content: "";
  float: left;
  width: 16px;
  height: 16px;
  margin: 0 5px 0 0;
  background: url(sprite.png);
}

.save a:before { background-position: 0 0; }
.edit a:before { background-position: -16px 0; }
.delete a:before { background-position: -32px 0; }

Using pseudo-elements like this helps to avoid the need to either add liberal amounts of white space to sprites or use empty HTML elements to do the cropping. Fiddle with the code in this example.

Pseudo background-position

The CSS 2.1 specification limits the values of background-position to horizontal and vertical offsets from the top-left corner of an element. The CSS Backgrounds and Borders Module Level 3 working draft includes an improvement to the background-position property to allow offsets to be set from any side. However, Opera 11+ is currently the only browser to have implemented it.

But by using pseudo-elements, it’s possible to emulate positioning a background image from any side in any browser with adequate CSS 2.1 support –’pseudo background-position‘.

Once a pseudo-element is created, it must be absolutely positioned in front of the associated element’s background but behind its content, so as not to prevent users from being able to select text or click on links. This is done by setting a positive z-index on the element and a negative z-index on the pseudo-element.

#content {
  position: relative;
  z-index: 1;
}

#content:before {
  content: "";
  position: absolute;
  z-index: -1;
}

Now the pseudo-element can be sized and positioned to sit over any area within (or beyond) the element itself, without affecting its content. This is achieved by using any combination of values for the top, right, bottom, and left positional offsets, as well as the width, and height properties. It is the key to their flexibility.

In this example, a 200px × 300px background image is applied to the pseudo-element, which is also given dimensions that match those of the image. Since the pseudo-element is absolutely positioned, it can be offset from the bottom and right of the associated HTML element.

#content {
  position: relative;
  z-index: 1;
}

#content:before {
  content: "";
  position: absolute;
  z-index: -1;
  bottom: 10px;
  right: 10px;
  width: 200px;
  height: 300px;
  background: url(image.jpg);
}

Many other hacks and effects are possible using the :before and :after pseudo-elements, especially when combined with CSS3. Hopefully this introduction to pseudo-elements, and how they can be exploited, will have inspired you to experiment with them in your work.

The future of pseudo-elements

The way that pseudo-elements are used will continue to change as CSS does. Some new applications will emerge, and existing ones will fade away as browser implementation of ‘CSS3 modules’ continues to improve.

Generated content and pseudo-elements themselves are likely to undergo changes too. The CSS3 Generated and Replaced Content Module introduced a two-colon format for pseudo-elements (i.e., ::before) to help distinguish between pseudo-classes and pseudo-elements. But for compatibility with previous levels of CSS, pseudo-elements do not require two colons. Most modern browsers support both formats, but it is not supported by IE 8 and the single-colon format ensures greater backwards compatibility.

The proposed extensions to pseudo-elements included 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). However, the CSS3 Generated and Replaced Content Module is undergoing significant changes.

This article was originally published in .net magazine in April 2011

Related resources

• Interactive examples of the code throughout this article
• CSS generated content techniques
• Automatic numbering with CSS counters
• CSS image replacement using pseudo-elements
• Multiple backgrounds and borders with CSS 2.1
• CSS background image hacks
• A whole bunch of amazing stuff pseudo-elements can do

A new image replacement technique was recently added to the HTML5 Boilerplate project. This post explains how it works and how it compares to alternative image replacement techniques.

[15 December 2012] This technique is no longer used in HTML5 Boilerplate. It’s been replaced by another, more reliable approach.

Here’s the CSS behind the recent update to the image replacement helper class in HTML5 Boilerplate. It has also made its way into the Compass framework.

.ir {
  font: 0/0 a;
  text-shadow: none;
  color: transparent;
}

What does each declaration do?

• font:0/0 a – a shorthand property that zeros out the font size and line-height. The a value acts as a very short font-family (an idea taken from the BEM implementation of this method). The CSS validator complains that using 0/0 in the shorthand font property is not valid, but every browser accepts it and this appears to be an error in the validator. Using font:0px/0 a passes validation but it displayed as font:0/0 a in the code that the validator flags as valid.
• text-shadow:none – makes sure that any inherited text shadow is removed for the text. This prevents the chance of any text shadow colors showing over the background.
• color:transparent – needed for browsers than don’t completely crush the text to the point of being invisible. Safari 4 (extremely rare) is an example of such a browser. There may also be mobile browsers than require this declaration. IE6/7/8 don’t recognise this value for color, but fortunately IE7/8 don’t show any trace of the text. IE6 shows a faint trace.

In the HTML5 Boilerplate image replacement helper, we’ve also removed any border and background-color that may be on the element. This makes it easier to use the helper class on elements like button or with links that may included background or border properties as part of a design decision.

Benefits over text-indent methods

The new technique avoids various problems with any text-indent method, including the one proposed by Scott Kellum to avoid iPad 1 performance problems related to large negative text indents.

• Works in IE6/7 on inline-block elements. Techniques based on text indentation are basically “broken”, as shown by this test case: http://jsfiddle.net/necolas/QZvYa/show/
• Doesn’t result in any offscreen box being created. The text-indent methods result in a box being drawn (sometimes offscreen) for any text that have been negatively or positively indented. It can sometimes cause performance problems but the font-based method sidesteps those concerns.
• No need to specify a text-alignment and hide the overflow since the text is crushed to take up no space.
• No need to hide br or make all fallback HTML display:inline to get around the constraints of using a text indentation. This method is not affected by those problems.
• Fewer styles are needed as a result of these improvements.

Drawbacks

No image replacement hack is perfect.

• Leaves a very small trace of the text in IE6.
• This approach means that you cannot use em units for margins on elements that make use of this image replacement code. This is because the font size is set to 0.
• Windows-Eyes has a bug that prevents the reading of text hidden using this method. There are no problems with all other screenreaders that have been tested. Thanks to @jkiss for providing these detailed results and to @wilto for confirming this technique works for JAWS 12 in IE 6/7/8 and Firefox 4/5/6.
• Like so many IR methods, it doesn’t work when CSS is loaded but images are not.
• Text may not be hidden if a visitor is using a user style sheet which has explicitly set important font-size declarations for the element type on which you have applied the IR class.

It’s worth noting that the NIR image replacement technique avoids these drawbacks, but lacks support in IE6/7.

Closing comments

I’ve been using this technique without significant problems for nearly a year, ever since Jonathan Neal and I used it in a clearfix experiment. The BEM framework also makes use of it for their icon components. The core idea was even proposed back in 2003 but the browser quirks of the day may have prevented wider use.

If you come across any problems with this technique, please report them at the HTML5 Boilerplate GitHub issue tracker and include a test case when appropriate.

Translations

• Nouvelle méthode de remplacement de texte par une image

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.

This is how I am deploying the build of my static website to staging and production domains. It requires basic use of the CLI, Git, and SSH. But once you’re set up, a single command will build and deploy.

TL;DR: Push the static build to a remote, bare repository that has a detached working directory (on the same server). A post-receive hook checks out the files in the public directory.

Prerequisites

• A remote web server to host your site.
• SSH access to your remote server.
• Git installed on your remote server (check with git --version).
• Generate an SSH key if you need one.

On the server

Set up password-less SSH access

First, you need to SSH into your server, and provide the password if prompted.

ssh user@hostname

If there is no ~/.ssh directory in your user’s home directory, create one: mkdir ~/.ssh.

Next, you need to copy your public SSH key (see “Generate an SSH key” above) to the server. This allows you to connect via SSH without having to enter a password each time.

From your local machine – assuming your public key can be found at ~/.ssh/id_rsa.pub – enter the following command, with the correct user and hostname. It will append your public key to the authorized_keys file on the remote server.

ssh user@hostname 'cat >> ~/.ssh/authorized_keys' < ~/.ssh/id_rsa.pub

If you close the connection, and then attempt to establish SSH access, you should no longer be prompted for a password.

Create the remote directories

You need to have 2 directories for each domain you want to host. One for the Git repository, and one to contain the checked out build.

For example, if your domain were example.com and you also wanted a staging environment, you’d create these directories on the server:

mkdir ~/example.com ~/example.git

mkdir ~/staging.example.com ~/staging.example.git

Initialize the bare Git repository

Create a bare Git repository on the server. This is where you will push the build assets to, from your local machine. But you don’t want the files served here, which is why it’s a bare repository.

cd ~/example.git
git init --bare

Repeat this step for the staging domain, if you want.

Write a post-receive hook

A post-receive hook allows you to run commands after the Git repository has received commits. In this case, you can use it to change Git’s working directory from example.git to example.com, and check out a copy of the build into the example.com directory.

The location of the working directory can be set on a per-command basis using GIT_WORK_TREE, one of Git’s environment variables, or the --work-tree option.

cat > hooks/post-receive
#!/bin/sh
WEB_DIR=/path/to/example.com

# remove any untracked files and directories
git --work-tree=${WEB_DIR} clean -fd

# force checkout of the latest deploy
git --work-tree=${WEB_DIR} checkout --force

Make sure the file permissions on the hook are correct.

chmod +x hooks/post-receive

If you need to exclude some files from being cleaned out by Git (e.g., a .htpasswd file), you can do that using the --exclude option. This requires Git 1.7.3 or above to be installed on your server.

git --work-tree=${WEB_DIR} clean -fd --exclude=<pattern>

Repeat this step for the staging domain, if you want.

On your local machine

Now that the server configuration is complete, you want to deploy the build assets (not the source code) for the static site.

The build and deploy tasks

I’m using a Makefile, but use whatever you feel comfortable with. What follows is the basic workflow I wanted to automate.

1. Build the production version of the static site.

   make build
   

2. Initialize a new Git repo in the build directory. I don’t want to try and merge the new build into previous deploys, especially for the staging domain.

   git init ./build
   

3. Add the remote to use for the deploy.

   cd ./build
   git remote add origin ssh://user@hostname/~/example.git
   

4. Commit everything in the build repo.

   cd ./build
   git add -A
   git commit -m "Release"
   

5. Force-replace the remote master branch, creating it if missing.

   cd ./build
   git push -f origin +master:refs/heads/master
   

6. Tag the checked-out commit SHA in the source repo, so I can see which SHA’s were last deployed.

   git tag -f production
   

Using a Makefile:

BUILD_DIR := ./build
STAGING_REPO = ssh://user@hostname/~/staging.example.git
PROD_REPO = ssh://user@hostname/~/example.git

install:
    npm install

# Deploy tasks

staging: build git-staging deploy
    @ git tag -f staging
    @ echo "Staging deploy complete"

prod: build git-prod deploy
    @ git tag -f production
    @ echo "Production deploy complete"

# Build tasks

build: clean
    # whatever your build step is

# Sub-tasks

clean:
    @ rm -rf $(BUILD_DIR)

git-prod:
    @ cd $(BUILD_DIR) && 
    git init && 
    git remote add origin $(PROD_REPO)

git-staging:
    @ cd $(BUILD_DIR) && 
    git init && 
    git remote add origin $(STAGING_REPO)

deploy:
    @ cd $(BUILD_DIR) && 
    git add -A && 
    git commit -m "Release" && 
    git push -f origin +master:refs/heads/master

.PHONY: install build clean deploy git-prod git-staging prod staging

To deploy to staging:

make staging

To deploy to production:

make prod

Using Make, it’s a little bit more hairy than usual to force push to master, because the cd commands take place in a sub-process. You have to make sure subsequent commands are on the same line. For example, the deploy task would force push to your source code’s remote master branch if you failed to join the commands with && or ;!

I push my site’s source code to a private repository on BitBucket. One of the nice things about BitBucket is that it gives you the option to prevent deletions or history re-writes of branches.

If you have any suggested improvements, let me know on Twitter.

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.

The previous night, they had called up relatives in Madhya Pradesh to say they were in a helpless state

TrueNat machines will be used for the first time in the State for virus screening

HDIL promoter is lodged in Arthur Road Central Jail

Airline brings them to Mumbai airport

With a view to prevent him from acting in any manner prejudicial to the maintenance of public order, Naeem Akhtar detention is being extended, an order said.

Court wants decision on levying costs for transport of migrant workers

This has been the highest spike in the number of cases in the State in a single day, taking the number of cases to 1,678

The NCMC chaired by Cabinet Secretary Rajiv Gauba met on Friday to review the situation arising out of the gas leak

All returnees are taken to centres from buses and trains

State health officials are planning extensive tests

Swindling, Linda Byars, 1965-

Plenert, Gerhard Johannes, author

Galliers, Robert, 1947-

Görög, Mihály, 1951-

Godfrey, Paul C., author

Stegmann, Juan Pablo