Las Vegas Web Designer Ecommerce Website Design

Earlier this month, Chris Coyier posted an article discussing a way to deal with the empty elements that are often needed when doing CSS3 animation.

Chris’s solution is interesting. He basically suggests (and I’m paraphrasing here) that we can give the empty elements semantic value by adding some text in each one to describe what each animated element does, or what mood it conveys. Then, the text in those empty elements can be moved off the page with CSS.

Some people got in a tizzy over the potential SEO penalties that could arise (which I kindly pointed out is probably not an issue) while others seemed to have a problem with Chris’s use of the word “semantic”.

I wanted to post a comment that would give my take on the matter, but I wanted to mull it over a bit. And now, I feel it’s better to write a quick post on this, rather than comment on the original post where it’s more than likely that the conversation has died out.

What About JS Injection?

UPDATE: One thing I neglected to take into consideration is when the elements in question would look just fine when they’re already in the HTML and they aren’t animating. So, with graceful degradation in mind, if the animated elements are crucial to the branding and overall look of the site, then naturally you would allow them to be static elements that only animate in supporting browsers. So in such a case it would not be a good idea to insert the elements with JavaScript.

The one thing that I think everyone in that discussion seemed to miss was the fact that it’s probably always best to use JavaScript to inject those types of elements. Isn’t this always the case with this type of thing? If someone has JavaScript disabled, then there’s a pretty good chance they don’t want to see a CSS3 animation.

The problem here is that the empty elements are not necessarily being acted upon by JavaScript. So it’s understandable that our tendencies towards “accessible HTML” would dictate that we try to overly-semanticize everything that’s not dependent on JavaScript.

So I think in this case, a CSS3 animation is no different than any widget in a web page that’s entirely dependent on JavaScript. So it should be added to the page with JavaScript. From my understanding, this would solve the SEO issue, would keep you from having to worry about empty elements littering your HTML, and you wouldn’t be giving screen reader users any odd elements with “moody” text.

UPDATE: From doing some research on how screen readers treat JavaScript, it seems that they will have the ability to read any content inserted with JavaScript, but only if the user actually focuses on it. This is the same as any content that a screen reader user tries to access. So, from an accessibility standpoint, whether you have the HTML there already or you insert it with JavaScript, there seems to be no difference.

What About JSHTML?

Finally, one last suggestion for something like this is a solution called JSHTML created by James Podolsey a few years ago. I really don’t know what the status of that JSHTML project is, or if James still recommends using it, but I personally love what it does.

Basically, JSHTML helps you quickly locate in your markup where dynamic content is inserted by placing that markup inside your HTML within HTML comments. Nicholas Zakas recently discussed how HTML comments are accessible in the DOM. JSHTML does something similar, which looks like this:

<div class="content">

	<!-- JSHTML {{
		<div class="animation-1"></div>
		<div class="animation-2"></div>
		<div class="animation-3"></div>
	}} -->

</div>

When the JSHTML script runs, it will parse your page looking for HTML comments with the JSHTML flag and delimiters (in this case, the double curly braces), then it takes the HTML from inside the delimiters and injects it into the page, at the same location where the comment was found. My brief summary of what it does might be technically off, but that’s the gist of it.

So this has a number of benefits:

• There’s no real empty elements in the markup to cause “semantics” problems;
• You can clearly see in your markup where the HTML will be injected;
• You can see exactly what will be injected; and
• You can change what’s going to be injected right inside the HTML comment (because that’s where the JavaScript gets it from)

Overall, I think something that uses JavaScript to inject the extra elements will work better because it’s more consistent with how we’ve done things with this type of content in the past.

If I’m overlooking anything here, I’d be happy to get some feedback.