Why inline styles with strict doctypes?

Well. Why not? Roughly a week ago Roger Johannson popped the question of why is the style attribute allowed in strict doctypes, and to the defense of it staying in the specs, I say it belongs. Now just hear me out because surely there's some wacko in the W3C that is thinking the same thing I'm thinking. To set the record straight. Let's take a brief review of what this is all about. Web Standards. Yay! Everyone applaud and put on their standardista t-shirts. One aspect of Standards that I firmly believe in is the separation of the three layers. I typically like to refer to them as the trinity of front-end development. Those three layers being the following:

Content and markup which is the (X)HTML.
Style and Presentation via CSS.
Behavior and Interactions by scripting the DOM via JavaScript.
~~AJAX!~~ I just had to do it as a joke.

So with those three layers - it is highly recommended and encouraged to separate them into separate work spaces which can all be edited per individual bases. Right. We all got that by now yea? Good.

So, inline styles, how's that fit into this theory?

Well, dare I say, that 'ol <font> tag wasn't so bad (ok, yea that is bad). The fact of the matter is this. I think, in one way or another, style gives meaning. One thing that people often don't understand is why there is a <pre> element which is often used to get that pre-determined whitespace look we love when displaying code on the web. Well, some would argue that that is an abuse of the pre tag, however it is indeed giving meaning to the content that it contains. That whitespace actually has meaning. For instance:

pre example



// this

var foo = ' ';

// is different than this

var foo = '      ';

Indeed the two variants of the 'foo' variable are different.

JavaScript animation

Another thing to consider about the style attribute is that without it, it would be virtually impossible to do JavaScript animation and have a valid DOM. And don't gimme that vudu magic trickery of an answer that says you can do all that with class names. Because, well actually, you can. But why? That's just outright stupid. I could just imagine seeing this written out:

animation with class names

<style type='text/css'>

/*

  To get that oh so perfect 45 degree angle

  using class names

*/

#anim-area div {

  position:absolute;

}

.a1 { top:1px;left:1px; }

.a2 { top:2px;left:2px; }

.a3 { top:3px;left:3px; }

.a4 { top:4px;left:4px; }

.a5 { top:5px;left:5px; }

.a6 { top:6px;left:6px; }

.a7 { top:7px;left:7px; }

/*

  I've already wasted my time and I'm only 7 pixels in...

*/

</style>

The point of that example is to show that it's just impractical. Moving beyond something that probably didn't even need to be brought up is just basic inline styles here and there. You know, those ones you want to drop in the middle of a blog post... like... Did you know that China has a red flag? Now think about it for a second. Did the fact that I just made that word red give it any more meaning? I think it did. Color presents meaning, and don't even try to convince a Graphic Designer otherwise (FYI - that would not be me, but rather someone like Jason Beaird).

And what about inline attributes in general?

Just think about it. What about the lang attribute for what it's worth? If you view source on this very webpage you'll find at the very top this line of code:

the language declaration

<html 

  xmlns='http://www.w3.org/1999/xhtml' 

  lang='en' 

  xml:lang='en:us'>

What that means is that I'm telling the client, the search bot, the whoever, that this document is in U.S. English. But what about those clever times when you feel like writing a sonnet? Or a simple phrase in another language? The common Howdy ya'll for you Texas folk. Or the ever popular spanish slang Ándale pues buey. Qué pasó? That typically means I want to override my default English base and set something in stone in my HTML because it gives my content meaning. Back to another code example, I think inline styles are perfect for displaying code on the web, especially when displaying color-coded code. To me, the use of colors on code adds yet another layer of meaning when I'm interpreting it. For instance take any blog post from Dean Edwards and you'll notice that after the DOM has been manipulated, inline style attributes are used to enhance the readability of the code. To me, that's useful! Whether they were present before or after - it's just plain and simply useful. On toggling the display of an element - although a tougher case to make, I can see how display:none; is used to convey a message of this information is not of importance right now... but it can be later. But hey, you're either convinced or you're not. I won't take it personal if you think I'm full of crap.

Use of style attributes responsibly

But of course, all this goes without saying that if you're ever going to be using inline styles anywhere in your document (and you've bought into my theory), ask yourself if it's appropriate and if it actually enhances the meaning of your content. Granted if your site becomes bloated with inline style attributes, don't say I didn't warn you. Use them responsibly and appropriately. I am the biggest advocate of separating your three layers as best as possible and would never recommend developing core websites like that. Inline styles should pretty much never show up as part of your template and be avoided at all costs in that manner. This more or less goes along the lines of in the middle of a blog post or similar places. Please ~~drink~~ use style attributes responsibly.

follow me

i am dustin diaz