The end of the clearfix hack?

A new value of the display property has landed in Chrome Canary and Firefox Nightlies. In the Editor’s Draft of the CSS Display Module Level 3, display: flow-root is defined as:

“The element generates a block container box, and lays out its contents using flow layout. It always establishes a new block formatting context for its contents.”

The key use of this comes when you have a box with a floated element inside it, and the floated element is taller than the other content inside the box. Default behaviour is that the box will not clear the float, and anything that comes afterwards will also wrap the floated item.

A screenshot of an element floated beside some text, with the containing element only containing the text, with the floated element bleeding through the bottom.
The floated element is out of flow causing the box to collapse.

The typical way we have solved this issue is to use a clearfix hack. The hack inserts some generated content, sets it to display; table or display: block and then clears it. This then ensures that the box becomes self-clearing, in our example the border will display after the floated item, and any following content will not rise up to wrap the float.

Enter display: flow-root

Using display: flow-root on an element will perform this clearing for us. Instead of needing to apply the clearfix hack we can use the CSS display property on the container with a value of flow-root.

Code language: CSS

.container {
  display: flow-root;

The border then clears the float and following content displays after our contained floated element.

The container element from the previous screenshot now has display: flow-root; which causes the container to properly contain the float, without the need for the clearfix hack.
After setting display: flow-root; on the container, the float no longer escapes the flow.


There is some discussion about the name of the value on an issue posted to the CSS Working Group GitHub. If you want to see interoperable support for this feature soon, then I’d suggest you pop over to the Edge UserVoice site and give it a vote.

WebSlides: Create Beautiful HTML Presentations

WebSlides makes HTML presentations easy.
Just the essentials and using lovely CSS.


Each parent <section> in the #webslides element is an individual slide.

Code is clean and scalable. It uses intuitive markup with popular naming conventions. There’s no need to overuse classes or nesting. Making an HTML presentation has never been so rewarding.


Safari bug with gradients that fade to "transparent"

Say you have a gradient in CSS that goes from red to transparent. Easy, right? Like this:

Code language: CSS

.element {
  background: linear-gradient(
    to bottom,

There is a pretty big gotcha here, though.

In Chrome (also Android), Firefox, and Edge, you’d be all good.


But in Safari (also iOS), you’d not be good.

The same test page as before, viewed in both the iOS simulator version of Safari, and the macOS version of Safari. The two rectangles, each with a gradient background colour are different this time. The red in the rectangle on the left fades from red to black, as it fades to transparent, which appears to be a bug. The rectangle on the right fades to transparent while still maintaining the red colour, as expected.
The element on the left in each browser demonstrates the problem.

The problem, the best I understand it, is that transparent is being interpreted (and interpolated) as “transparent black”.

To fix it, you have to set the color as a fully transparent version of that exact color. Like:

Code language: CSS

.element {
  background: linear-gradient(
    to bottom,
    rgba(255, 0, 0, 0)


Sass can help out, if you are using that:

Code language: Sass

.element {
  background: linear-gradient(
    to bottom,
    rgba(#eb8fa9, 0);

The limits of @supports

@supports may be very useful, but it can only tell you so much, especially in the case of browsers that will return true, technically supporting the feature, but having a buggy implementation. This is a case where we can often assume too much about a browser based on a reductive test that isn’t guaranteed to tell us what we think it does. PPK explains:

If a mobile browser doesn’t support background-attachment: fixed in practice, what happens when you do this?

Code language: CSS

@supports(background-attachment: fixed) {
	// CSS

Does it return false because the mobile browser doesn’t support it? Or does it return true because its desktop version supports it? With my background-attachment test data in hand I could now answer this question.

All mobile browsers return true for both fixed and local. Only 3 out of 23 browsers speak the truth here. See the test case and the inevitable table for more details.


What’s clear from these tests is that @supports is only useful when you’re detecting entire CSS modules such as flexbox. So the check below makes sense.

Code language: CSS

@supports (display: flex) {
	// flexbox layout
@supports not(display: flex) {
	// float layout

This example is likely safe. If a browser decides to support flexbox, display: flex is the first item on the agenda, so detecting it makes perfect sense. (It’s theoretically possible, though, that a browser fakes display: flex support in order to end up on the right side of some support detects. But as far as I know this is not the case today.)

On the other hand, if a browser has flaky support for, I don’t know, justify-content, a more precise check like this may or may not work, depending on how the CSS parser is written:

Code language: CSS

@supports (justify-content: space-around) {
	// may or may not fire correctly in case
	// of a browser bug

So this example is unsafe. Don’t use @supports for such detailed compatibility questions.

Vertical viewport units are unreliable on mobile

When I was first styling Resilient Web Design, I made heavy use of vh units. The vertical spacing between elements—headings, paragraphs, images—was all proportional to the overall viewport height. It looked great!

Then I tested it on real devices.

Here’s the problem: when a page loads up in a mobile browser—like, say, Chrome on an Android device—the URL bar is at the top of the screen. The height of that piece of the browser interface isn’t taken into account for the viewport height. That makes sense: the viewport height is the amount of screen real estate available for the content. The content doesn’t extend into the URL bar, therefore the height of the URL bar shouldn’t be part of the viewport height.

But then if you start scrolling down, the URL bar scrolls away off the top of the screen. So now it’s behaving as though it is part of the content rather than part of the browser interface. At this point, the value of the viewport height changes: now it’s the previous value plus the height of the URL bar that was previously there but which has now disappeared.


In my initial implementation of Resilient Web Design, the one where I was styling almost everything with vh, the site was unusable. Every time you started scrolling, things would jump around. I had to go back to the drawing board and remove almost all instances of vh from the styles.

A Comprehensive Guide to Font Loading Strategies

This is an incredibly thorough guide to web font loading strategies, and their pros and cons.

If you’re looking for a specific approach, I’ve prepared some handy links that will take you to the section you need. Let’s say you want an approach that:

  • is the most well rounded approach that will be good enough for most use cases: FOUT with a Class.

  • is the easiest possible thing to implement: I’ve learned a lot about web fonts and at time of writing this article the current browser support is lacking for the easiest methods for effective/robust web font implementation. It is with that in mind that I will admit—if you’re looking for the easy way out already, you should consider not using web fonts. If you don’t know what web fonts are doing to improve your design, they may not be right for you. Don’t get me wrong, web fonts are great. But educate yourself on the benefit first. (In Defense of Web Fonts, The Value of a Web Font by Robin Rendle is a good start. If you have others, please leave a comment below!)

  • is the best performance-oriented approach: Use one of the Critical FOFT approaches. Personally, at time of writing my preference is Critical FOFT with Data URI but will shift toward Critical FOFT with preload as browser support for preload increases.

  • will work well with a large number of web fonts: If you’re web font obsessed (anything more than 4 or 5 web fonts or a total file size of more than 100KB) this one is kind of tricky. I’d first recommend trying to pare your web font usage down, but if that isn’t possible stick with a standard FOFT, or FOUT with Two Stage Render approach. Use separate FOFT approaches for each typeface (grouping of Roman, Bold, Italic, et cetera).

  • will work with my existing cloud/web font hosting solution: FOFT approaches generally require self hosting, so stick with the tried and true FOUT with a Class approach.

Hiding DOM elements - ally.js

This document explains the various ways of hiding things and the implications that come with that.

When we say an element is hidden, we usually mean it is not visible. However, the screen is not the only output mechanism we may need to hide content from. Systems like screen readers and braille displays rely on a document’s representation in the accessibility tree. For disambiguation we’ll use the following terms:

Completely hidden
The element is not rendered on screen, not exposed in the accessibility tree, not accessible to keyboard navigation.
Semantically hidden
The element is rendered on screen, but not exposed in the accessibility tree, and still accessible to keyboard navigation.
Visually hidden
The element is not rendered on screen, but exposed in the accessibility tree, and still accessible to keyboard navigation.


How to hide elements completely

Completely hiding elements can be done in 3 ways:

  • via the CSS property display, e.g. display: none;
  • via the CSS property visibility, e.g. visibility: hidden;
  • via the HTML5 attribute hidden, e.g. <span hidden>

While each of these techniques has the same end result, i.e. content is not rendered and not exposed in the accessibility tree, they have different behaviors.


How to hide elements semantically

To hide content from the accessibility tree but retain the content on screen, we may use the attribute aria-hidden="true".


2016 edition of .visuallyhidden


Code language: CSS

.visuallyhidden:not(:focus):not(:active) {
  position: absolute;
  width: 1px;
  height: 1px;
  margin: -1px;
  border: 0;
  padding: 0;
  clip-path: inset(100%);
  clip: rect(0 0 0 0);
  overflow: hidden;
  • It works in all modern browsers including Internet Explorer 9 - 11.
  • It side-steps the need to re-style everything for focusable elements such as skip-links.
  • It accounts for the deprecated clip property.

Keyboard navigation

The techniques to hide elements only visually or semantically come with a caveat. Focusable elements like <a href="…"> remain keyboard navigatable, even though the element is not visible on screen or not exposed in the accessibility tree.

To make sure sighted keyboard users do not end up focusing elements they can’t see, and screen reader users not focusing element’s that don’t exist for them, we need to make sure that partially hidden content is not accessible to keyboard navigation using the Tab and Shift Tab keys. To accomplish this, we can add tabindex="-1" to the elements we want to hide from the keyboard.


  • Use the hidden attribute to completely hide an element.
  • Use the aria-hidden attribute to hide an element from the accessibility tree.
  • Use the .visuallyhidden class to hide an element from the screen.
  • Use visibility: inherit; instead of visibility: visible; to avoid accidentally showing content.
  • Do not attach any CSS styles to the aria-hidden attribute.
  • Take care of keyboard focusable content that is partially hidden by adding tabindex="-1".