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.
June 15th, 2006 at 1:48 am
I couldn’t get by without inline styles, sometimes I’ll use them in one off scenarios so the stylesheets don’t get cluttered.
Zeldman refered to them in his web standards book as like ‘touch up paint’. Of course the practical implications, and sometimes performance issues make the use of the style attribute indispensible when doing DHTML
June 15th, 2006 at 2:02 am
It is a valid attribute, so I can imagine that people will use it since it can come in handy. I don’t boughter as long as they use it responsibly. I don’t use the style attribute, it makes me feel a kinda bit dirty, but that just my thought about it.
Although, about the chinese flags case: I would choose for an em or a strong and add the color with a class, instead of using a span + style attribute. You want to emphasize it, em or strong would be more semantic in this case I think.
June 15th, 2006 at 2:13 am
There is a difference between a style attribute in (X)HTML and the style object in the DOM. Disallowing the attribute would have no effect on the object, as these things are specified differently. Heck, they work in a different manner!
June 15th, 2006 at 2:35 am
Mark, yeah, you can use
document.writeand say that you’re not using embed tag. ;)Dustin, thanks for this article. I haven’t agreed with Roger following Emil on though that style=”" is not so ok with strict doctype, and you cleared up my mind finally.
June 15th, 2006 at 3:30 am
Be carefull with this interpretation that style attribute can have meaning.
You say: the chinese flag is red (span style=”color:red”) then I can say the Mount Everest is 8848m height (span style=”height:8848m”)?
June 15th, 2006 at 3:43 am
Your thing with the
langattribute is a little off… You see, the idea is, you can apply lang to the<html>, and then the standard language will be whatever you specify.If you then inside your document embed some text in another language, you simply apply
langto that piece of text. Wrap it in a span if there isn’t any tag surrounding it. You see? :)June 15th, 2006 at 4:31 am
I would not like to see the ’style’ attribute go away, but in the case of a strict DOCTYPE, I can see the point that Roger Johannson is making. However, I’d say this is only true for a strict XHTML document.
XHTML is actually XML and if you are going to claim strict XML you should be writing strict XML. In an XML document, you simply wouldn’t place styling in the document. This gives XML extreme flexibility in the mediums it can be used in, and you the developer extreme flexibility in how you can present your documents.
If you are writing pages with a strict XHTML DOCTYPE, there are really only two reasons for it, IMO. 1) You want or need the flexibility and power of XML so that you can transform your document between mediums and environments. 2) You think it’s neat to say you’re writing XHTML Strict so you can look good to your web neighbors. ;) Reason 1 is one of the real goals of XML, and a reason to stay away from ’style’. Reason 2 is somewhat pointless (though I have done it many times) and it really doesn’t matter what attributes you use.
Just a thought.
Jim
June 15th, 2006 at 8:04 am
Pure separation of content and presentation just doesn’t exist is actual usage. Even when we used typewriters (some of us anyway), writers put headings on separate lines to indicate they were not sentences. Italics are used to indicate something about the content, e.a. this is a title or a foreign phrase. Addresses have breaks in them to indicate what is a street name and what is a city name. Even an un-styled html document still has default presentation.
June 15th, 2006 at 8:10 am
I like to think of it as a three-layer cake. Mmmm…yummy.
Seriously though. I have no problem with writing the style attribute using DOM scripting. But placing it in the markup directly? It doesn’t feel right to me. But hey, that’s just me.
I totally hear what you’re saying about color adding meaning. That is why we typically use the color red for error messaging. But here is the kicker. Even if you use the inline style attribute to turn words red, if styles are turned off, the meaning is lost. There is no semantic value to the style attribute. Hmmm…perhaps there should be an element in HTML 5.
I typically mark up error messages with or and style appropriately with CSS. That way with styles turned off, emphasis is still applied and the meaning remains.
June 15th, 2006 at 8:12 am
I meant to say… I typically mark up error messages with <em> or <strong> and style appropriately with CSS. That way with styles turned off, emphasis is still applied and the meaning remains.
June 15th, 2006 at 8:14 am
@Pete: Yea. That’s a very good way of explaining it. I know Mike Davidson is one to drop the ocassional
class="blue"here and there which ultimately is just achieving the same effect. “Touch up paint” is a nice way of putting it.@Jano: Haha. Yea. I would want to stay away from putting a large height on something like that.
@Jonathan: That’s exactly what I did. Did you view source? ;)
@Mark: The style object and style attribute are different via DOM and HTML, but you must admit, they’re achieving the same goal.
It’s almost like doing that awkward work-around for opening up links into a new window by adding a target attribute into the anchor element with JavaScript rather than just setting it in the HTML.
@Jim: True that. That’s definitely the case I can see Roger was trying to make. However XHTML is not XML in the case of its ability to use as many tags as you’d like. Since it’s still based off the HTML set, you can only do so much with so little. Another thing is that even if it was pure XML, you should be able to use any attribute you want :)
June 15th, 2006 at 8:20 am
But you can. You simply need to edit the DTD and point your DOCTYPE to your new version rather than the one existing already. XHTML truly is pure XML.
June 15th, 2006 at 8:22 am
@Steve: I definitely agree. But think about really disabling styles. If styles can get truly disabled fully, then you wouldn’t be able to understand anything at all. It just so happens that when you disable styles via Developer Toolbar or what have-you, that doesn’t disable your default browser styles on your system… so we still see things like big headers, block elements, bold, italic, etc…
If you look at it from the markup perspective, the markup is all still there live and kicking, whether it be
<strong>or<span style="font-weight:bold;">.@All: None of this is to say that I’m promoting the use of inline styling your webpages. That’s not where I’m getting at. I definitely think inline styles should be used very, very rarely. But when you have to, don’t feel dirty. It’s just HTML.
June 15th, 2006 at 8:24 am
Jim, Roger was speaking directly on behalf of XHTML 1.0 strict - and then even XHTML 2.0. I forgot to communicate that.
June 15th, 2006 at 9:59 am
I agree Dustin, inlines styles are here to stay.
One thing that comes to mind is tag clouds. Compare the way Flickr does it to Technorati. I like Flickr’s solution a million times better.
On my site I use absolute positioning where the distance from the left is a function of time. There is no way that would ever work without inline styles.
June 15th, 2006 at 10:43 am
Oh crap, I forgot to postable my code before posting. Here’s my post again, if you could just delete that last one…
The way I see it is this:
Say I’m right in the middle of writing a hot blog post and I decide an image would go really nicely with this. The image happens to have a smaller width than my content area, so I think floating it might do nicely.
Being the standard-aware type of person I am, I give my image a class, search my computer for that damn stylehseet, create a new class, and walla.
You have to be kidding me.
(Besides, I like script.aculo.us too much.)
June 15th, 2006 at 10:46 am
I use them for little style touches not worthy of a being “classed”, or for cases where classes are meaningless. For example, in http://www.mundoplus.tv/programacion/parrilla.php I show a TV programming grid with a style switcher. One of the styles positions each event based in the starting time. Am I supposed to have to define 1440 (presentational) classes? No way :P
June 15th, 2006 at 1:12 pm
Dustin++. Good points!
Actually, it was Emil Stenström whom first posed the “inline styles in strict doctypes” question.
I still think inline styles is a decent enough as far as separating structure from presentation. Perhaps not as good as external stylesheets, but it can be maintained much easier then resorting to transitional doctype (maintenance / separation).
Following on Elliot Swan above, in practical terms, it can be much more beneficial to style up a unique page/element, where it is hardly or not in use on the remainder of the site. No need to clutter the main stylesheet.
On a spin from colours conveying information, here is one of my favourite URLs regarding psychological properties of colour.
June 15th, 2006 at 1:42 pm
If you resort to using it, should you really be able to use the strict doctype; the doctype with means “I really have separated my content from my presentation”? The use of it is when those two collide, when the content of the page is the presentation of it (designers, like Dustin says, will claim all their designs are really content). You need to draw the line somewhere and I think that line should be drawn stricter in strict.
A lot of examples in the comments above can be solved by dynamically writing CSS to a block at the head of the document. That’s a prettier way imo.
Conserning JS animation I have to go with Mark Wubbens comment, use the js style object if you want but don’t use the style attribute. I’m mainly conserned with content/design mixing since I don’t know as much about js. I can guess though that it could easily get messy if too much design goes into the behaviour layer.
Lastly, Janos comment is really telling: Adding a span with style=”color: red” is not a good way of conveying information. I divide things into four layers where the fourth one is content. If you want to add content to your page, add it as content, not through the structure layer.
(It’s interesting to see that everyone agrees with you in this thread and everyone agrees with Roger in his ;)
(One last thing. I’m not really as unreasonable as one could think reading what I wrote above, but it’s not as easy as you portray it in your post)
June 15th, 2006 at 2:08 pm
How about this:
I’ll try quickly highlight a critical point which gives a proper justification to most of this in the real world.
Cost!
That’s right. We cannot in all cases, develop a site that is purely obeying the 3 commandments of separation, then some accessibility guidelines, or even get to attend usability issues. There are always compromises.
We can even go further and get technical as far outlining the complexity of development and how we got here in the first place.
Ideally, one would love to do all these things, however we have to remind ourselves that, we are using these technologies to get our jobs done. We cannot on the contrary become a victim as a purist and shape the end goal to meet imperfect specifications, and even in cases where therein lies interpretating W3C documents.
Getting back to 4 layers of content as highlighted above, dynamically creating styles is NOT always possible, and can be costier to get into then a simple ‘inline’.
IMHO
June 16th, 2006 at 1:24 am
Unlike folks like Dustin, in the world of coding & design, I’m a virtual ‘nobody’. I mean, when I code & design sites, I try to stick to the rules & do all the things that the cool kids are doing on the web.
That being said, I have to agree with Dustin on this. Even Thomas Fuchs of Script.aculo.us fame [which I'm sure you all know] gives developers a tip by saying “don’t use display:none in external CSS”
But then again, who am I??
June 17th, 2006 at 1:35 pm
> gives developers a tip by saying “don’t use display:none in external CSSâ€
I think by “tip” he means that if you put display:none in your CSS files, then scriptaculous effects *will not* work at all.
June 18th, 2006 at 9:28 am
there should be a way to tell when JS is not off and CSS is off
June 18th, 2006 at 9:30 am
style attributes cannot be off, with css you can.
June 19th, 2006 at 3:56 am
Johan, a dirty but working way is to set a height of an element specifically with CSS and read out the offsetHeight with JavaScript. That way you can check if CSS is off but JS in enabled.
test script here
June 19th, 2006 at 4:11 am
I am sorry, but the “tip” about not using display:none in an external CSS is just plain glossing over architectural problems in your own script. If none of the visual effects of your library works when the CSS has been developed not according to your library then you have forgotten that the web is different development streams working together and not for your script or library. Whoever worked in a framework/cms environment quickly learnt that there is no such thing as having full control over all 3 (well I say 5) layers.
I fully agree with some of the comments here that defending style attributes by explaining the need for style properties for drag+drop is not applicable.
It is like saying body onload is fine as you can set a window.onload handler.
I also agree with Roger that there are cases where an inline style attribute is needed, and these are the ones where you need for example different background images maintainable in a CMS but you cannot change the CSS document. I had to use that in the past, too.
Then again, if you want to develop for the web and browsers exclusively, strict XHTML is not applicable as it is anyways (text/html vs. xml application header issue)
June 19th, 2006 at 5:05 am
> Johan, a dirty but working way is to set a height of an element specifically with CSS and read out the offsetHeight with JavaScript. That way you can check if CSS is off but JS in enabled.
Thank you for your the testpage. I used a similar technique to detect for images off scenario.
This could be handy for SIFR (flash text replacement) when CSS is off, you see flash txt an d unstyled txt
June 26th, 2006 at 5:43 am
Inline styles are all but required by the third layer you presented (functionality). Without it we wouldn’t have access to a number of things within the [object].style arena. Sure, you can do a lot with predefined classes (I usually toggle an object’s display using the [object].className property) but a number of things are just easier with the inline style properties available within JavaScript. I’d hate to have to create a new class in my CSS for every one-off I’ve ever done, and in some cases it would just be plain impossible.
January 30th, 2007 at 11:06 am
I found another issue in xhtml 1.0 strict:
onload doesn’t work on elements like span! Or dit I do something wrong?
The folowing code is generated by my php-script.
Normaly php generated as follow:
I have tricked my php-script, and now i can insert the title between span-elements.
Thanks that i have applied some variables on other elements, i can also link a background to the main-div, and a background-image to the header.
If JS is enabled this backgound-image can replace the title, because the on the hole div there is an onclick atribute
But if JS is disabled there is no atribute onclick, so i have to display the title.
I hoped that if i aplied OnLoad="this.style.display=’none’ on the span, i could hide the div for those with JS enabled, and Show the Title for those with JS disabled.
But it seems onload doesn’t work only for body.
But if i implent it in body, hole the concept of my dynamicly generated page is lost.
Here is the parsed code
Is there a solution for my problem?
July 31st, 2007 at 10:54 am
Hello Dustin,
What do you think about using document.styleSheet.* for javascript animation?
November 6th, 2007 at 1:49 pm
I use inline style to float individual tables and images to the right, set page breaks in quizzes and tests, and to put a bar on the letter x for the sample mean in documents. I could remove the inline style and replace with classes defined in the head, but I am simply using the head to accomplish inline style. For the sample mean, I have yet to find a UTF-8 character to use, MathML will not embed in XHTML and when I am whipping off a quick quiz I prefer HTML 5 to XHTML 1.0 + MathML (though I use it and the +SVG version when I really have to do so). I used to use images for xbar, but that seemed less appropriate for what is a actually a character in a test or quiz.