Fixing the flash of no-JavaScript styles

Cory Duncan — Tue, 24 May 2011 16:54:21 +0000

The flash of no-JavaScript styles (FONJS) happens when styles need to be applied to certain elements, but only if JavaScript is enabled. If the JavaScript doesn’t execute fast enough, the user may briefly see the no-JavaScript styles.

An example of where FONJS can occur is a tab interface, which consists of a list of navigation links (tabs) and the content they will activate (tab content). To consider the audience that may have JavaScript turned off or unavailable (for any number of reasons), we want the tab content to be accessible without JavaScript. When JavaScript is available, all tab content should be hidden, except for the active one. Conversely, when it’s not available, all tab content should be visible.



	Tab 1
	Tab 2


	Tab content 1


	Tab content 2

Implementing a solution

Option 1: `.js` class

This option is based on the idea that a .js class will be added to the element via JavaScript to craft styles that depend on JavaScript. FONJS is frequently observed when a JavaScript library (like jQuery) is used to apply the .js class, and particularly when that library is loaded at the end of the document. For performance reasons, we do want to load external scripts at the end of the document.

We need a fast, library-agnostic way of doing this, that will also maintain any existing classes on the element. To ensure the JavaScript will execute quickly enough, it needs to be embedded in the block.

Note: document.documentElement returns the root element of the document. In the case of an HTML document, this should always return the element.

Option 2:

Option ?

As with many things in web development, there are several solutions to this problem. I’ve documented the two approaches that I’m familiar with. If you have a different solution to this problem, please share in the comments area.

Don’t lose your :focus

Cory Duncan — Tue, 15 Sep 2009 23:21:41 +0000

CSS resets are great. Without them, our jobs as UI developers would be much more frustrating, or at the least, more tedious. They give us a (mostly) level playing field when building user interfaces that work across multiple browsers. My personal favorite, and probably the most-used reset stylesheet, is the one Eric Meyer has built and maintained. It works great and has solid reasoning behind it.

What does this have to do with the focus state? Part of the reset includes resetting the focus state style.

/* remember to define focus styles! */
:focus {
	outline: 0;
}

Note the comment there…

Resetting the focus state is fine, I’d encourage it in fact — the default browser focus state is ugly! Here’s an example of what the default focus state for Firefox (3.5 Mac) looks like:

Even though Eric explicitly states in his reset CSS to define a focus style, in my experience this step is often neglected. Without a focus style defined, using the keyboard as a navigation device becomes a more difficult task. Keyboard navigation may be an edge case, but a focus state should always be considered.

The simplest solution is to extend the hover style:

a:hover, a:focus {
	color: #666;
	}

With one extra selector, we’ve made the interface more accessible to keyboard navigation. For more complex interfaces with varying hover styles, you may need to declare more than one focus style, but that’s a small price to pay for accessibility.

Substance Labs » Accessibility

Fixing the flash of no-JavaScript styles

Implementing a solution

Option 1: .js class

Option ?

Don’t lose your :focus

Option 1: `.js` class