Semantic Animation

I recently said this when asked about new tools (e.g. Edge) for building CSS animations:

Empty divs used for nothing but styling were non-semantic and a bad idea before CSS animations and they are a bad idea now.

I stand by that. I feel like we've come a long way as an industry getting everyone on board with semantic markup. Do this, and reap the great rewards of speed, accessibility, maintainability, and SEO.

Then a new shiny thing comes along and the first thing we do is start abandoning our own rules. "Oooo I can make a bird fly across the screen‽" Order me up a few more of them empty divs! I'm surely guilty of this. It doesn't feel like that big of a deal when you're doing it, especially in moderation.

But CSS animations are here to stay. General best practices are going to emerge regarding what types of things we should be using them for, how much is too much, how to approach them semantically, how to offer fallback content, etc. I thought I'd throw in one little idea I had.

Let's consider what animations do for a design. They can give it mood. They can give it attitude. Like other aspects of design, they affect how a user might feel about that page. But they only do these things for sighted users. The empty div does none of these things for non-sighted users. It's just useless cruft.

What if we were to take that empty div and try to accomplish for non-sighted users all the same things we are accomplishing for our sighted users. Simply putting descriptive text into those divs might be able to get it done for us. Similar to an alt tag for images, but actual inline content meant to be read/enjoyed in same way the animation is meant to be seen/enjoyed.

Perhaps our animation is of a moon rising, and as it rises the sky and ground turn to black. We need two elements to accomplish our animation, and so perhaps they contain the lyrics to CCR's Bad Moon Rising

<div class="moon">
I see a bad moon rising
I see trouble on the way
</div>
<div class="ground">
I see earthquakes and lightnin’
I see bad times today
</div>

Notice the names of those keyframe animations. That's another discussion to have in the "semantic animations" vein. Another time.

This text could be anything that relates to the animation. It could describe the animation literally. It could be a poem that elicits the same emotion as the animation. It could be an <audio> element.

Woah there, fancy designer boy.

I don't use screen readers, so I don't get to make the call if this is a good idea or not. I imagine there is already enough cruft to fight through that this, despite the good intentions, might be just another thing obstacle on the way to "real content".

I suppose it's like everything else in this world: it depends.

Share On

Comments

Not so long ago I attended Andy Clarke’s Hardboiled talk and he touched on this same topic. He proposed describing the scenes in a list (possibly an ordered one at that) which gave a perfectly understandable experience to non-sighted users.

If anyone is wondering what Ryan is talking about, I think he means being able to use something like body:after(2) and add arbitrary elements to the page in which to animate and not worry about affecting semantics.

Good post, but even though I agree with your points, I’ve never felt comfortable with hiding text with ‘text-indent’. What if my screen was 9999px wide? Sounds stupid and not very likely, but I’ve never seen it as an elegant solution because of that. Plus it’s probably not very good for SEO.

What about removing it with JS? Do blind people browsers have JS enabled?

I have to agree with Chris on this one. Adding extra divs to markup doesn’t make it semantically wrong, but it breaks the separation of content and design, and it encourages messy markup.

It’s like there’s always a war going on between the people that want to keep HTML in its place (markup) and those that want to make it into some kind of data repository for scripting and design efforts. HTML was not built with the intention of creating complex animations.

From my personal view, animations should either be done with video or by using the canvas element — that’s one of the reasons it was created, and I’m surprised that no one has mentioned it. In fact, I’m surprised that Edge doesn’t use it; it would generate much cleaner HTML, and maintain the separation of the markup and programming.

Sounds like you’re using the broadly accepted and mostly wrong definition of HTML semantics.

DIV and SPAN elements have no semantic value. They’re completely neutral (safe for the occasionnal use of a lang attribute), and defined in the HTML spec as styling and scripting hooks. Adding a thousand DIV to an already semantic document doesn’t add or substract anything to the document’s semantics. Using empty elements (especially DIV or SPAN) for decorative purposes is not semantically wring. Limiting your use of those elements makes your code leaner, but not more semantic.

That being said, it’s a good idea to be critical of our use of those styling hooks. Some basic questions that are related to HTML semantics:
– Am I using a DIV or SPAN when another element would be more appropriate? (Yet be conservative. Replacing every sequence of DIV containers with an unordered list is not better semantics, it’s noisier semantics. Everything is a list if we take the definition of “list” too far.)
– Am I using an empty DIV or SPAN with CSS backgrounds, CSS generated content or scripting that convey a meaning? Can I put some or all of this meaning as text in the HTML document?

We should steer clear from dogmatic or simply wrong definitions of HTML semantics. Your article has great points when it comes to examples, but blanket statements such as “Empty divs used for nothing but styling [are bad]” are just wrong.

Adding a thousand DIV to an already semantic document doesn’t add or substract anything to the document’s semantics.

I take your point but hold to mine. Maybe there is an official definition of semantics I’m breaking, but, like the web itself, definitions are flexible and can change to accommodate new uses and meaning.

Wherever and empty or extra-wrapping div is used, I call it non-semantic.

Actually, I’m not sure your example is good. I’m wary of attempts to transcribe “mood” information in text. I could say the same for corporate identity values and all other information that a design tries to convey.

I mean, if you want to have a nice moody animation in a page and transcribe it as poetic text, fine. But most designers won’t bother, and users who will get the text version may not care or even think it’s a nuisance (noisy text that distracts them from their goal on the page, which might be getting to some useful information or filling and sending a form). It’s probably nice for a personal/poetic website, but useless for most of the real work we do.

Random idea: if you think some design/animation parts are indeed content and should be available as text as well, go the extra mile and offer this text to all users.

Finally, your text content will not be available to users when CSS styles are applied but a) the browser doesn’t support animations or b) images are not loaded for some reason (e.g. network issues). This is one of the common pitfalls of the negative text-indent technique, which is better than using display:none but still has accessibility issues. Sadly HTML has very little fallback mechanisms. (The alt attribute is one but it’s very limited, and the object element was supposed to offer one but it was badly defined in HTML4 and implementations in browsers are lacking; finally, HTML5 continues this tradition of poor fallback mechanisms by not exposing the fallback content of audio and video elements even when the intended media ressource is not available.)

I tend to agree with fvsch about mood: it’s rarely beneficial to “semanticise” it for screen-readers. Typically it would be annoying. I think this is more about geek-cred for the designer than helping users.

Wherever and empty or extra-wrapping div is used, I call it non-semantic.

…and I think you’re right: it is non-semantic. But I wouldn’t call it unsemantic. My suggested definitions:

Semantic markup: markup that makes good choices of HTML elements to add (machine-readable) meaning to the document

Unsemantic markup: markup that makes bad choices of HTML elements, which create a less meaningful document (or even a misleading document)

Non-semantic markup: markup that has no effect on the meaning of the document

Nice definitions. I may use them in the future. Your definition for “semantic markup” matches the HTML5 definition. The other two are quite logical and make an important distinction.

The issues we have with discussions of semantics in HTML is that everyone says that semantic HTML is a good practice, but there are quite a few confusions:

1. We tend to think that since semantic markup is good, then markup that is not semantic is necessarily bad. Not quite. Unsemantic markup is bad, non-semantic markup is neutral. (I guess extreme non-semantic markup is chaotic neutral?)

2. We tend to apply the “semantic HTML is good” principle to anything that could be arbitrarily called “semantic”. For instance we sometimes call HTML class names “semantic” when they describe the content, but that’s only one naming convention and there’s arguments that at least in some situations class names that describe the content are a bad practice (see the OOCSS and “modular CSS” principles).

Non-semantic markup is definitely appropriate in certain places, and CSS animations is a perfect example! Yes, it took a long time to get people to rally behind using semantics on the web, but in doing this we’ve almost completely scared people away from the possibility of non-semantic elements.

I’m not entirely convinced that what Chris is suggesting here would immediately be flagged by Google as spammy. According to the Google Webmaster link you cited, it says:

“If your site is perceived to contain hidden text and links that are deceptive in intent, your site may be removed from the Google index and will not appear in search results pages.”

Bold added. In this case, making the empty elements more semantic is not “deceptive”, so it won’t necessarily be penalized.

Also, this issue of hiding text and how Google views it has been addressed in relation to the issue of image replacement techniques. For example, see this article by David Shea, who summarizes Google’s view of hidden text:

Although image replacement techniques are not as relevant today, the same principle applies. Shea concludes by saying:

“Using CSS image replacement in a responsible way, where the image truthfully represents the content it’s replacing, is safe to use. The simple act of hiding text from users is not enough to get your site banned from Google’s index.”

Now, if Google’s view has changed since then, I’d like to see evidence of that. Otherwise, I think the same rule applies here. So you could change that quote to read:

“Using [CSS animation] in a responsible way, where the [animation] truthfully represents the content it’s replacing, is safe to use.”

But again, if there’s any other evidence to suggest Chris’s technique would cause problems, then I’d be happy to see it. But I think as long as the intent is not malicious or spammy, then it’s safe to hide text using CSS.

it’s funny.We always hypothesize about screen readers when there’s a demo for JAWS on their website and Fang ,the Firefox addon that translates web pages in text. As I was just reading about screenreaders,they sound really robotic and supposedly, users are used to hear the content really fast. So, I m not sure they really want to hear R2D2 reciting Byron on Meth!

@nick, @Binyamin… seeing you so fearful of Google’s (often capricious) systems, and actually having thought that image for text substitution was an accepted practice which was actually endorsed by Google, I followed the links offered by “Binyamin” above.

Frankly, I don’t see anything in Google’s position which even hints that they would penalize a site for using image substitution – without links or intent to hide key-words for SEO purposes. In fact, just the opposite. Google’s wording seems to me to offer “extra points” to improve the accessibility experience.

Additionally, I see nowhere that Google makes provisions for “dinging” a ranking for using hidden text. What they threaten is “removal” from the rankings! Dropping from 3 to 112 would make me consider that “someone” had discovered my income stream and was now using whatever techniques they could to take it away from me. That’s where I’d go for answers rather than blaming it solely on Google’s image replacement policies. (Of course that still doesn’t mean that Google’s algorithm which places churned, brain-dead blog content 12 result pages above full authoritative content pages doesn’t suck wind!)

I just wanted to throw my support behind the “Woah there, fancy designer boy” point, though I’m not a screen reader user either. Seems like a good test for whether alternative content is needed is to determine if the animation is trying to convey any information or if it’s just there as decoration.

For example:
– Animating a bar chart or a line graph to illustrate data changing over time: Yes to alternative text content.
– Animating a bird flying across the screen just because you can: No to alternative text content.

As a sighted user, I can understand wanting to convey the mood of a design. But I don’t believe anyone currently does this with non-animated design elements, and all the recommendations I’ve heard say don’t do it. If you have a static image of a bird flying across the screen, the alt text should not be “A picture of a bird flying across the sky.” The alt text should be an empty string: “”.

The idea of being semantic, doesn’t mean to provide content. Semantic technically and literally means “emphasis”, because it comes from the Greek work “sēmantikos” meaning “significant”. Now, when we use a header tag for our site’s header, that has nothing to do with the meaning of the work “header”. Rather, we emphasize that this is the header of our site.

I think a better name for what you described here in this article, Chris, would be accessible animation, rather than semantic animation. In your animation your not emphasizing anything by providing content to empty divs. You only provide something for sight-incapable people.

Where are the tools to really test a web-page with different sets of disabilities ? I’m sure browsing a site with only audio or braille would give a better feedback. Like we’re testing sites of IEx it would be nice to have these things in our toolbox.

Animation doesn’t equal presentation to me, and I pretty much believe CSS animations are a fad. Much like every single animated GIF that polluted the web not so long ago.

It’s also not realistic. By your standards, you should alternatively describe every single event & effect in the page (hover, focus, color change etcetera), not only CSS “special effects”. And that could get pretty messy real soon.

I can only imagine how annoying it gets after a while and how perfectly useless it is. Anyhow, from what I experienced so far (HI) that’s the idea: less is more.

I wouldn’t say CSS3 animations are a fad. There are many commonly used JS/Flash animations that can now be repalced by CSS3 animations. CSS3 aniamtions also provide better performance over JS/Flash animations in lower end computers and phone browsers.

And I’m saying that because specs creators just want to throw shiny stuff at makers & developers to get more attention.

Because browser makers pick those specs up and have giving up on *properly* implementing some basic and vital CSS stuff in favor of the newest CSS fads, in order to not lose ground with the user (or to gain ground even).

I would love to have a solid CSS base properly implemented first. I’d like to be able to enjoy my layout, not to worry about it. I’d like to be confident about using relative dimensions.

And a few others more I’d like to be fixed, in one UA or another, because none is perfect.

After these fixes, yeah, CSS animations are acceptable as *experiments*. But not before. And I’ll still believe CSS animations aren’t really presentation.

CSS animations beside some touchups (sliding, rollovers, parallax) is awkward right know. There are no advanced IDE tools like Flash to do it smoothly. And animation is often jerky and unpredictable in different browsers. I mean some animation above complexity of moving from point A to B in straight line.

I ‘d just to like to point out how happy I am about this article and especially the comments on here. This is what the web community is all about, getting together and discussing or debating the best way to do things, as well as sharing resources and tips. I think I’ve learned a lot, great stuff!

This comment thread is closed. If you have important information to share, you can always contact me.

Treehouse is where you go to learn HTML, CSS, and how to build iOS apps. It's a complete education in modern web and app technology, designed to get you ready for a hot new job or to kickstart your own business.

The Lodge is a member login only area with access to video training on how to build websites from scratch using the best modern tools.

What now? I have some ideas for you.

Go explore CodePen!

As a front end designer and developer, you should have an account on CodePen so you can save your snippets, present your ideas, and engage with other front end folk. I'd encourage you to go PRO as well, to unlock the full power of CodePen.

Get the newsletter!

You should sign up for the CSS-Tricks newsletter. It's a clean copy of all the blog posts each week, combined together, right to your inbox. If email isn't your thing, there is an RSS feed, iTunes, and lots of other ways to subscribe.

Listen to ShopTalk!

Subscribe to The Lodge!

The Lodge is a members-only, ad-free video learning area here on CSS-Tricks. Just like the free screencasts, but organized into four large complete series. Membership is also the #1 best way to support CSS-Tricks.

We can do the real footer now.

Site Links

Colophon

CSS-Tricks* is created, written by, and maintained by Chris Coyier. It is built on WordPress, hosted by Media Temple, and the assets are served by MaxCDN. The fonts are Source Sans and Source Code Pro. It is made possible by viewers like you who subscribe to The Lodge and through advertising for products and services I like.