Why is the style attribute allowed in strict doctypes?

The strict HTML and XHTML doctypes encourage the separation of semantic and presentational markup by disallowing the use of elements such as center, font and strike, and attributes like align, bgcolor, and border. So why is the style attribute allowed in strict doctypes? And why is it allowed (but strongly discouraged) in XHTML 2.0?

I admit that I sometimes use the style attribute. One example is when a site is designed to have a decorative photo as a background image in the masthead, and the client needs to be able to use the CMS to upload their own images. If the image is purely decorational it doesn’t belong in the markup and should be specified in the CSS, preferably in an external CSS file. But doing so would require the CMS to make changes to the CSS file, which few CMSs are set up to do out of the box. Using a style attribute is much more convenient. Every time I use one I feel a bit dirty though. It’s like using the javascript: pseudo-protocol or specifying event handlers like onclick inline. I’d rather avoid it.

An alternative approach would be to make the CMS write the necessary CSS to a style element in the document’s head section, using a class or an id to apply it to the element that holds the background image. While not the ideal solution it will at least let you get rid of those style attributes.

After reading the above, you’ll hardly be surprised that I agree with Emil Stenström: Inline CSS should not be allowed in strict doctypes. It seems like the logical choice since disallowing it would help enforce the separation of semantic and presentational markup. Then there’s always the faint hope that it would send a message to those CMS vendors who are particularly guilty of sprinkling style attributes all over the markup their products produce that they are not following best practices.

Posted on June 6, 2006 in (X)HTML, Quicklinks

Comments

  1. I recently ran into this with a recent site I built. Its for a comic series where I work (www.serenitybuzz.com). Right now, there are only 6 books in the series - but it needs to be expandable to more as we get more books in the system. This meant that IF books were added to our main database, they would show up without appropriate styles linked to the book unless manually added.

    For this, I used PHP - where I could simply serve up styles.php with a Content-type header of text/css, and then create the styles dynamically. (as a Side note - I did run into issues with this and output buffering in IE).

    Like you, I hate the idea of using inline CSS - so this was the solution I came up with.

  2. June 6, 2006 by Nathan Rutman

    I’m not sure inline styles should be removed from the specs quite yet. While I’m no advocate for their use, I do think it’s important to press the issue that “best practices” are just that — the best of allowable practices. Personally, I don’t see a need to conform the DTDs to the best practices. While they should certainly allow for best practices, they should allow more than best practices, in my opinion, if for no other reason than to encourage innovation with tools currently at the innovator’s disposal. Who knows, the style attribute might somehow become the next XMLHttpRequest (though doubtful, I’ll admit).

  3. June 6, 2006 by Stephen Hill

    I totally agree with you, however, i must admit that I too, out of lazyness, use the odd style attribute here and there.

    I really like Nate’s idea about producing a style sheet of the fly. I think this would help CMS’s out there.

    When it comes to a CMS, I have to blame the WYSIWYG Editors that come with them. Which place extra tags and invalid attributes all over the code it produces. To make some text bold, underlined and italic; it produced the following:

    Sample Text

    I agree more should be done and I think I should start removing style tags from my code :)

  4. The thing I’ve noticed is that when I bring code in with AJAX, that code doesn’t work with the style sheets, so I end up using the inline style attribute. Is there something I just don’t know about to get it to work? I wouldn’t be suprised if that were the case.

  5. While we seldom use style attributes in our markup, it is very common to use the DOM ElementCSSInlineStyle interface to set inline styles with JavaScript. My question is: If there were no style attribute in Strict, should DOM CSS still provide such an interface? Or would we have to use document.styleSheets to insert or update a style rule for the certain element? We should not forget this implication.

  6. June 6, 2006 by Stephen Hill

    If you are wanting to use JavaScript to define styles, then I would suggest using a defined class the the .css style sheet and add the class to the element like this:

    this.className += ” trhover”;

    This will then apply then apply the style to that element.

    This method is used in Jop de Klein’s Zebra Tables

  7. While your at it — as you said, tack on javascript pseudo-protocol (href=”javascript:”) to that list as well.

  8. I believe that the style attribute is allowed because the purpose of separation is nonetheless achieved via CSS. Whether it’s included directly in the page via inline styles or in a separate stylesheet, the presentation and structural layers are still kept separate. You have to remember that the push behind separation came from a) the misuse of structural elements such as the paragraph tag for adding spacing and b) the use of sanctioned structural markup for presentational purposes (such as and ). With CSS, all that is presentational is taken out of the markup and either relegated to a separate file, or to attributes within the markup which are exactly that, attributes, not actual markup. Therefore separation is maintained.

    The question is then not one of separation but one of efficiency. Is it more efficient and therefore simpler to maintain when we use separate stylesheets? The answer in most cases is yes. However, if you take that approach to the extreme you begin to introduce other problems such as the difficulty of maintaining separate stylesheets for different locales in the case if image replacements etc… Or, you start generating stylesheets (which introduces all kinds of overhead) simply to avoid using an inline style attribute.

    I think what’s called for isn’t so much a fundamentalist and/or extremist approach where everything is black or white. Rather, if we are to treat our trade as the art form that it is, and if we are to call ourselves seasoned professionals, then we should implement the years of wisdom we’ve acquired and make educated judgment calls as to when and where to use the tool provided to us in the form of the style attribute.

  9. Separation is maintained when you have structure and content in HTML files, presantation info in CSS files, and javascripts in their own files. If one stuffs everything into “style” or “onwhatever” attributes, that’s just a big mess, not a separation. For me code with style attributes looks worse than one with infamous font tags. Yes, I did use “style=…” too, but now my vote goes for “no style attribute in strict doctypes”.

  10. Ara, you are dead on my man. I get worried when I start seeing terms like “should never be allowed.” I’m all for standards and clean code believe me, but let’s not jump over the cliff with some of this stuff.

    I’ve found in working with the Dojo toolkit in a pretty complex web app that sometimes inline styles are written out dynamically, and sometimes we’ve had to override some styles inline for various reasons.

    Our code is still organized, and as Ara said - still separate. But it had to be done to satisfy the business cases.

    It’s one thing to recommend a practice, it’s another thing to force it upon everyone without thinking it out all the way through. Inline styles are generally not a good idea, but there are times when they are both needed and appropriate.

    Let the developer make that decision, not some standards body.

  11. Content and style separation is a good thing, but if the style’s in style=”“, it’s separated. The content itself is still marked up semantically - it’s just that the style is close to the content. It’s close, but still separated! Keeping the style further away from the content, such as in the header, makes it easier to avoid repeating your CSS; keeping it in a separate file makes it easier to switch styles, avoid changing modification dates, etc.

    That said, I keep all my CSS in separate files, but I don’t think it should be the law.

  12. June 6, 2006 by Scott

    I suppose I’m guilty of using inline styles if that is considered a crime. I attribute it partly to laziness, but also partly to the fact that the site I work most on has a badly written stylesheet which I haven’t had the courage or time to tackle. I’m currently in the slow process of rolling up all those inline styles into the external stylesheet, but unfortunately it ends up at the bottom of my priority list because my pointy-haired boss doesn’t understand the importance.

  13. +1 to Rick, Tom and Ara. An ad banner does not belong to the presentation layer, and is usually managed (uploads, rotations) by the CMS. I see it as a case where it makes more sense to use a style attribute.

  14. A strict doctype is meant to be strict. I think that inline styles should be deprecated in strict doctypes because unlike external scripts and style sheets (which are defined in the head section - where meta data and non-HTML resources belong), style attributes are a part of the body (which should only provide structure). Using inline styles is not separating structure from presentation because you are not separating the HTML from the styles.

    I’ll admit that I’m guilty of using inline styles from time to time just like everyone else, but that’s not an excuse to allow poor standards.

    To answer the people complaining that they need inline styles, I’ll refer you to the quote on Emil’s site:

    I hear the obvious reply: “What if I load design info from a database? I need to use inline CSS then!”. To me, that sounds like a perfect case where you need to go transitional, if you can’t manage to separate the two - don’t.

  15. I have been trying to catch up with the state of standerds based web design, to impliment into projects I have been working on. I can say is that everytime there is something thrown at this community that seems to be an insermountable issue, someone steps from the shadows with a new and innovative way to resolve it (think getting around the flash embedded issue with javascript within a week or so). I think if the decison to move to a even more restrictive strict doctype definition that these issues mentioned in the comments will be resolved extremely quickly. Also how fast does the entire development world adopt a “standard” doctype? HTML 4.0.1 was defined Christmas Eve (Dec 24) 1999.

    Just an observation keep up the great articles / blogs.

    RobbieTheGeek

  16. Thomas: So then I’m sure that you also advocate the deprecation of JavaScript’s style attributes since their use would mean mingling the presentational and behavioural layers. Oh and while we’re at it, let’s not use the “:hover” pseudo class either for exactly the same reason.

    Okay, now I’m just being facetious ;-) Especially since I’ve already written about this before.

  17. June 6, 2006 by Cameron

    inline style attribute is great for a one-off formatting that will never be used anywhere else in the application.

  18. June 6, 2006 by Vladimir Orlt

    I’m not an expert (yet :-) and I don’t use CMS (yet, which lands me in an ideal world :-) but yes, it seems to me that if you plan your CSS classes properly, you shouldn’t need in-line CSS at all. My understanding of in-line CSS is that it mainly acts as an override of ‘global’ CSS settings.

    (PS againn, why are geocities URLs considered spam?)

  19. I occasionally use inline styles. Pretty much 100% of the time, it’s due to a CMS writing the style in for better control of client-placed images or the like.

    On one site, for example, the primary article images had a light gray border around them, but some images looked better without the border. Checking a “no border” box next to the field where the client entered the article image wrote in “style=’border: 0;’” to the image tag. (for various reasons, the CMS would not write to a class attribute without serious hacking)

    Anyway. Maybe someone can explain precisely why inline styles should be removed from the strict doctype? In my case, there is clear separation of style and content, the rest of my example site is as standards-friendly as can be, and, of course, everything is well-formed and valid. So I don’t understand where the problem lies.

    Is it because it can be easily misused? Flash can be misused—I don’t see anyone trying to removed Flash from any strict doctype. I’m sorry, but this seems to be a clear example of “standaristas” at work.

  20. I guess on the standards front I don’t really understand the urgent need to rip away things that has helped implement better standards. The more you take away the more you lose track of whats important. And what’s important is presenting well designed layouts that abide by most if not all web standards (as much as a situation can allow anyway).

    The style attribute whether you feel it is or not is a part of the fabric that is web standards. Honestly, like others have mentioned, it still has its place just like HTML has always had since the advent of xhtml. When xhtml started to become widely recoginzed, there were rumors and heresay of “the end of html”. But yet it still remains. Cause it has context and it has relevance in developing websites.

    New standards in building web apps specifically excel on the existence of the “style” attribute. Take that away and then you have to refactor the way your web apps work on the presentational front.

    All in all, I agree the style attribute is not exactly what we call a gem of standards based design, but its certainly an important (and relevant) part of the process.

  21. Not every UA is capable of getting external stylesheets —Opera 8 and its first implementation of SVG.

    Sometimes you need an element to retain some styling even when external CSS is not available.

    DTDs are not a nanny who must forbid you doing dangerous stuff.

  22. June 7, 2006 by Tommy Olsson

    It’s obvious that some of the readers here don’t quite understand the concept of separating structure from presentation.

    Separation of structure from presentation means that you can change the appearance of the document without changing the document itself.

    With style attributes, you will have to edit the document markup (attribute values are part of the markup). That means it’s not separate.

    There are cases where it’s tempting to use inline styling, but I’ve yet to encounter one where it’s actually necessary. However, polluting a global style sheet with dozens of classes or IDs that are used only once in an entire site seems wasteful as well.

    As usual, limitations in CM systems and authoring tools are the problem when trying to accomplish clean, semantic markup.

  23. June 7, 2006 by Roger Johansson (Author comment)

    Like Tommy says, using the style attribute does not separate semantic and presentational markup. I don’t see how you can claim otherwise. The only separation it introduces is that a user agent that does not support CSS will render a document completely unstyled whether the CSS is defined inline or not.

    Of course there can be circumstances, especially concerning some badly built CMSs, that simply force the use of inline CSS. That doesn’t make that practice any better or mean that we shouldn’t try to avoid it.

    If you want to - or have to - keep using inline CSS, all you need to do is stick with one of the current doctypes. They won’t change. If you want to be lazy and keep producing sloppy code, just ignore validation errors and/or use a transitional doctype.

    The current working draft of XHTML 2.0 also allows the style attribute, but has the following to say about its use:

    Note: use of the style attribute is strongly discouraged in favor of the style element and external style sheets. In addition, content developers are advised to avoid use of the style attribute on content intended for use on small devices, since those devices may not support the use of in-line styles.

    As for HTML 5, Anne van Kesteren posted an interesting comment on Emil’s article:

    I agree that the [style] attribute should not be used though and as far as I know HTML5 does not have it as part of the allowed attributes.

  24. Important: Please do not forget scoped style sheets! This is still a draft, but a very interesting approach which can (and for some will) make a huge impact on how to work and simplify your code!

    Example from the draft:

    style=”@import url(navigationstyles.css);”

    …and the most interesting excerpt:

    the use of @import which apples [sic] the referenced style sheet to the subdocument consisting of the element and its children with the element as the root

    Personally, I’m really looking forward to this profile, and thus I see no need to “curse” the “style” attribute. It just needs to be used appropriately, as everything else.

  25. Update: I just asked the CSS Working Group about scoped style sheets (again). Although Jukka K. Korpela once pointed out that the mentioned draft might be misleading.

  26. June 7, 2006 by Roger Johansson (Author comment)

    Jens: Interesting indeed. Sort of like using an id selector but with even higher specificity. I can’t see any immediate use for it though. Do you have a specific example?

  27. Like Tommy says, using the style attribute does not separate semantic and presentational markup. I don’t see how you can claim otherwise.

    Okay, but in what context? If the part of my document that contains the hard-coded HTML is completely separate from both my stylesheets and the CMS which inserts the style attribute, is that still considered separation of style and content? Is it only the final, rendered HTML that makes the difference?

    I fail to see the negative effect an occasional style attribute would cause, other than the goal of picture-perfect markup. Can anyone provide an example?

  28. June 7, 2006 by Roger Johansson (Author comment)

    Yes, in my opinion only the final, rendered HTML matters in this case.

    If used with care, style attributes don’t necessarily cause any negative effects. When used incorrectly, such as by some CMSs, they can increase the weight of the HTML considerably.

    A few examples of the problems I see with inline CSS:

    • Media specific stylesheets: How do you turn off inline CSS for a mobile phone or when printing?
    • Backwards compatibility: How do you hide inline CSS from old browsers?
    • Browser filtering: How do you specify alternate inline CSS for buggy browsers?
    • Maintenance: When maintaining and updating the site, how do you keep track of what is defined inline and what is defined in external style sheet files?
  29. I find inline style attributes to be useful for testing minor changes to the presentation of existing pages and before they are moved permanently to an external style sheet.

  30. Roger, those are valid issues, but I would argue that those are issues that arise from the misuse of inline styles, not the use of them.

    Take my example of the CMS writing “style=’border: 0;” as an attribute to an article image:

    • Media specific stylesheets are otherwise not affected adversely, or are easily overruled by the “!important” rule

    • Backwards compatability is not an issue

    • Browser filtering, again, is not an issue

    • Maintenance, although arguably an issue here, is really no more difficult than keeping track of which data is hard-coded and which is controlled via CMS.

    In my opinion, a strict doctype isn’t there to “nanny” a developer, it’s there to let the document parser know just what kind of code it’s going to be dealing with. It’s the developer’s responsibility to use inline styles (as well as div tags, span tags, font tags kidding, kidding!) with restraint and common sense.

    Why take away a tool just because some people don’t know how to use it correctly?

  31. Yea, I’ll double the comment (if any) on the mere fact that JavaScript animation simply just wouldn’t be possible without the use of inline styles…. Well… it can, but that would look real messy in a style sheet.

  32. June 8, 2006 by Roger Johansson (Author comment)

    Richard: Sure, doing something as simple as removing the border from an image is very unlikely to cause any major problems. I was thinking of more extensive use of inline styles, like this (copied straight from a “valid” site):

    style="z-index:795;position:absolute; top:440px; left:770px; height: 37px; width: 138px; overflow: visible; "
    

    Just one snippet from a site that passes validation and touts itself as being web standards compliant and accessible.

    Of course it’s the misuse of the style attribute that is problematic. Developer responsibility, while a nice ideal to strive for, just doesn’t seem to work. We are a lazy bunch and tend to take any shortcuts that we can, so we do need a bit of nannying. If you don’t agree, no problem. Just keep using the current doctypes :-).

    Dustin: Yeah, that would be messy. I don’t think inline styles would need to be removed from the DOM though.

  33. Update: Bert Bos answered:

    The CSS WG considers it [scoped style sheets] a potentially useful feature, but currently of low priority.

    @Roger: Well ;) At last, the more complex the structure of your documents, the more useful scoped style sheets might get. Basically, you can (massively) simplify your CSS rules by using simpler selectors, it also (partially) prevents specific rules from affecting the rest of documents.

    One example I can think of includes one problem we faced at GMX, a communication service, to offer HTML email previews within a single HTML file. Since we included a GMX specific header including all email information like recipients, subject, and so on, we needed to make sure that style sheets included in the presented email wouldn’t harm or distort this information. We worked around that by elegantly “exhausting” the entire cascade, that is, using important and very specific selectors, including the foreign style sheet first, and even by generating random IDs (and corresponding selectors) to make sure chances are low anybody modifies something unintended. (This clearly was a must for us.) Long story short, scoped style sheets would have helped us in this situation.

    Other examples will easily come up whenever you think about overly complex selectors and/or sometimes overwriting existing declarations. Surely, fully implemented CSS2/3 selectors will help a lot to make work and code easier - I can’t wait, really -, but scoped CSS could be an additional weapon. Which, of course, needs to be used appropriately, but that’s no news, right ;)

    @Richard: In the mentioned case, why don’t you just define

    @media all {
    a img { border: 0; }
    }
    

    ? Using individual measures for e.g. images and tables was the only reasonable and/or “valid” use case I see for “style” attributes.

  34. The style attribute is a useful tool. It’s a very powerful tool too, and like most power tools should be used responsibly, and preferably by someone who knows what they’re doing. Used responsibly - i.e. sparingly if at all - it can be handy. Mostly a new id would do just as well (though isn’t necessarily ‘better’). But using the odd inline style doesn’t make you a ‘bad’ developer which is where this discussion seems to be heading.

    I have to agree that including inline styles in XHTML2.0 does seem to conflict with the goal of removing presentational markup from HTML. That is, however, if you take ‘separation’ to mean that an html document should only contain purely structural markup, with all presentationl/behavioural markup stored separately. It you do there is a good argument that the current XHTML2.0 spec doesn’t take this concept as far as it could (though I’m sure it takes it quite far enough for most people) and that inline styles, possibly along with embedded styles, don’t have a place in the spec. The counter argument is Ara’s one that the separation principle is about language (html for structure, css for presentation) not where the language is stored. At that point inline and embedded styles aren’t a problem.

    Whichever side of this theoretical fence you’re on, though, the mistake is thinking that tightening up XHTML2.0 will give us better code. The problem is simple, but one no spec can fix: valid code isn’t good code. Just as writing which is free from spelling mistakes and grammatical slips isn’t necessary good writing, so code which validates to a certain standard - transitional, strict, html, xhtml - isn’t necessarily good code. It is merely accurate code. It’s a start, and an important one at that, but only a start.

    So an occasional lapse into laziness by a good developer isn’t the problem. The problem is abuse of the style attribute (or any other part of the html spec) to tick a standards-compliance box by developers - particularly CMS and web editing software developers - who understandably confuse validating to a certain doctype (i.e. complying with a published standard) with what most people here would mean by “web standards-compliance”. But tighter specs won’t (and don’t) fix this. The ‘lazy bunch’ simply take Roger’s advice, stick with an older doctype, and still give themselves their standards-compliance brownie points. Good developers find themselves mocked when messy, everyday project requirements mean they can’t validate their latest project to the latest spec.

    We need to hammer away at the concept that using and complying with a certain doctype is only a very small part of what we mean by “web standards”. We need more articles like Mike Stenhouse’s latest advocating good coding practices and explaining their benefits, and a lot less of the macho posturing from some people which accompanies their discovery of an unencoded ampersand here, or a transitional doctype there.

  35. The only time I will add an inline style is during a test mock-up on a standalone document and then I rarely do that.

    I see no reason for inline style attributes (except for extreme conditions out of the authors control) and I never use them live.

  36. Scoped CSS looks good.

    We’ve got a problem with a CMS we are implementing, were our styles are cascading into the WYSIWYG editor we are using, causing some bizarre display issues. We’re finding it very difficult to circumvent the issue, but scoped CSS would have been a godesend.

  37. June 22, 2006 by Mike Healy

    I think Ara Pehlivanian got it right. Use external CSS docs via classes and IDs for the vast majority of styling, but don’t spontaneously combust in a hysterical semantics meltdown if the odd style attribute proves to be more effecient.

  38. July 17, 2006 by Martin

    I think the question is framed incorrectly. The question is not Should inline presentation be allowed in doctypes? but Is inline presentation ever good practice?

    Then, the debate can continue with Should strict document types enforce best practices? And also Should XHTML (or any good markup language) enforce best practices?

    I think that strict HTML documents should strictly use best practices. Transitional documents can strive for best practices, but fall short occasionally.

    I believe XHTML ought to be a distillation of the best practices of HTML and XML. Frankly, I’m a little surprised that XHTML needs a transitional doctype. XHTML is a chance to wipe the slate clean of previous mistakes, so why not enforce best practices?

  39. I’ll admit that I’m guilty of using inline styles from time to time just like everyone else, but that’s not an excuse to allow poor standards.

  40. One solution to that problem could be to use PHP to show the file the user has uploaded, and then in your style sheet put:

    header {

    background: url(“image.php”); }

    I’ve used this for one of my own designs to generate a random header image.

Comments are disabled for this post (read why), but if you have spotted an error or have additional info that you think should be in this post, feel free to contact me.