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?
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.
Actually, your idea has won me over from the first read.
It makes sense. A lot. And I think the article about using :before to add an image to a button can also benefit for an JS injection solution or from a JSHTML approach.
As a personal view on that article, talking about semantics for design elements may seem like a good idea until it becomes annoyingly informant. Less is more. “A picture speaks a thousand words”. You can’t really beat that, and HI captioning is proof.
JSHTML…..that is the most bizarre idea I think I’ve ever seen. Instead of putting redundant markup in your page, you put redundant markup in your page and use Javascript to show it? Just because it’s in comments doesn’t make it any less semantic when you *do* show it, nor does it reduce any of the “clutter” of extra elements (in fact, quite the opposite).
Furthermore, you’re not doing anything to improve accessibility – whether the elements are empty or non-existent in the DOM, a blind user won’t know anything about the animation. A more realistic solution would be a universal ALT tag – something like
I’m not sure you understand what redundant markup is, to start with.
A blind user could care less about efforts directed towards meaningless semanticising. And so would a normal user. There is a time when too much is too much, even with semantics.
The next step is: “A background of something”, “A transition on hover like this”, “A change of color on click like that”, “A gradient of autumn red and rainy blue”, “A logo of a mid 16th century sword on a recycled red paper”. It sure seems a bit frustrating to constantly being reminded of what they’re missing, every other meaningless element.
Content is king. Markup is the one doing the dirty work. It’s the way it is.
In that case who cares about empty, insemantic elements? Screenreaders will just ignore them anyway.
P.S. The phrase is “couldn’t care less”.
Agreed. But that’s the reason they’re better off being injected with JavaScript. It’s not necessarily that they’re bad for screen readers, it’s that since they’re not adding any actual “content”, then you might as well keep them completely hidden from bots and assistive devices.
Of course, I’m not an expert on screen readers so I’m really not sure if something like JSHTML would hide those elements from all users.
Correction:
After some research, it seems that screen readers do have the ability to read content that’s injected with JS, but only if the user actually focuses on that content. So, either way, for screen readers, it’s pretty much the same as regular content that’s not inserted with JS.
So, I don’t necessarily think it’s wrong to have empty elements, nor do I think Chris Coyier is wrong for suggesting adding descriptive text.
I just feel that this type of thing is better off being injected with JS, and leaving your markup clean (or semi-clean, in the case of JSHTML).
Empty elements equals syntax, that’s how *I interpret*.
I agree, semantics could care less about empty elements ;) http://www.dailywritingtips.com/could-care-less-versus-couldnt-care-less/
And a JS injection is most likely the best option here, if one suddenly feels more catholic than the pope ;)
Less is more. That’s what I’m saying. Keep it simple. For you and for your user. No matter what user.
interesting.
my main thought here is how is the AT reliant user is going to view it? i realize that sounds a bit far-fetched, but i’ve been thinking about demos alot lately, and considering the markup i commonly see, i imagine AT users are left out. Since they’re demos, who cares, right? But what about the up and coming AT reliant developers?
maybe the ideal solution is to come up with an accessible markup dev toolkit? like boilerplate or twitter bootstrap?
i’m not disagreeing with ya, i like your approach, just repeating the voices that i hear in my head.
For those who don’t know, AT = “Assistive Technology” like screen readers.
I don’t think my article here has really solved this problem. It’s just an option. I’m just surprised that nobody in the comments in Chris’s article suggested inserting the content with JavaScript, so I wrote this.
If screen reader users can see JavaScript inserted content (and it seems that they can), then it’s the same in terms of accessibility. I still think it feels better inserting these things with JavaScript instead of having them in the natural DOM.
I think it would be ideal if we could accomplish the following:
1) Show the animation to all traditional users
2) Have no extra elements in the natural HTML
3) Insert the extra elements with JavaScript
4) Make the extra elements invisible to screen readers.
I think #4 is the only one that is not resolved. Other than that, I think inserting the elements with JavaScript is a pretty good choice.
I’ve updated the article because I didn’t really consider the situation where animated elements could just remain static in nonsupporting browsers. If this is the case, then I think it’s wise to have plain empty elements right in the HTML, and if you feel the need, add some text in there and move it off screen with CSS.
But if the elements are entirely dependent on JavaScript or CSS animation and would somehow harm the experience if they just sat there without animating, then I think it would be best to insert them with JavaScript.
In that case who cares about empty, insemantic elements? Screenreaders will just ignore them anyway.
Hi,
The animation is now much attractive now in web media and this page is informatics and helpful. HTML5 and CSS3 powerful tools and need to understand. It is incredible effort and I really like it. I am facing the problem in my code that is not compatible with all browsers. Please help me how I can compatible my HTML5 and CSS3 code with all browsers.