Inline CSS should not be allowed in strict doctypes

about

Emil Stenström blogs about web development. Posts are bi-weekly.

To the about section

popular

These are the most popular articles (by number of comments):

1. Levels of CSS knowledge
2. Beginner’s guide to CSS
3. Why XHTML is a bad idea
4. How to structure large CSS files
5. Encyclopedia of HTML elements
6. Cross browser CSS for your site
7. Real hackers don’t use CSS
8. Inline CSS should not be allowed in strict doctypes

To the list of all articles

1. Sarven Capadisli 28 May

   01

   Perhaps it would be ideal to dynamically apply a selector to the element instead of an inline style.

   However inline styles seems to come in handy as a quickfix, where it may be more costy to apply the styles on an external stylesheet?

   To answer your question, why the proper inline styling in Strict doctypes is better then transitional inline styling.. well, one can still easily remove styling from the markup without actually touching the HTML components. It is a minor separation in affect, but still containerizes styling as supposed to mixing markup and styling on the same level.

   Having said that, I agree, although inline styles are allowed, they should be discouraged for use in Strict doctypes.

2. Dennis 29 May

   02

   Good point, Emil. Your example is a good illustration of why inline CSS isn’t much of an improvement. Sarvin makes a good point, too, in that inline CSS is good for a quick fix only, which I have been guilty of once in a great while. Hopefully if a web developer is smart enough to use XHTML strict, he will not be writing inline CSS.

3. Emil Stenström 29 May

   03

   @Sarven: A “quickfix” sounds just like throwing in a little table here and there. I also don’t agree that we are dealing with “minor separation”. The style attribute is embedded design, nothing else.

4. Ara Pehlivanian 29 May

   04

   Not even in the case where you’re doing Image Replacements for multiple languages and are dynamically pointing to different images based on the locale that’s available as a variable in the page?

   Then again, I suppose you *could* write a dynamic stylesheet that would contain all of the style rules w/ variables (i.e. in a .php file).

5. Emil Stenström 30 May

   05

   @Ara Pehlivanian: The point here is that you want separation of design and content. How is adding an image with style separation? I agree that it’s harder to do it without using style but isn’t that a typical transitional page?

   Like you say, most of the problems can be solved with a dynamic CSS-file, that is, dynamic design instead of dynamic content.

6. karl 2 Jun

   06

   Use Case.

   Wysiwyg environment:
   Cut and Paste (with style) from one document to another one.

   How do you move the style context?

   It’s not that easy. :)

7. Emil Stenström 2 Jun

   07

   @karl: I would say it is that easy. Are you saying that it should be ok to embed style in content because it’s hard to do otherwise programmatically? Transitional certainly sounds like the solution to that problem.

8. Anne van Kesteren 6 Jun

   08

   It’s not about DOCTYPEs anymore. They are merely a way of telling the browser which rendering mode you want in text/html.

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

9. Sarven Capadisli 6 Jun

   09

   Just wanted to reiterate the point of why inline styles are better then going ahead with transitional methods (your question); with inline styles, styling is still containerized for a given element (just as internal stylesheets), and they can be safely removed or altered without touching the actually structure of the document.

   On the other hand, with transitional markups, deprecated code allows the developer to mess with the ’structure’ of the document for presentational purposes and surely if they wish to apply any changes, it can be troublesome.

   Proper XHTML [content type, real XML markup (side note to those use trailing spaces and then a slash on empty elements.. there is no such thing in XML - such convention is introduced to cater older browsers)], enforces this idea of separation even further. HTML however, is not as… lets say ’strict’.

10. Robert Nyman 6 Jun

    10

    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.

    While I agree with your general notion of separating CSS from the HTML, I disagree with the above comment. Naturally the style attribute could be removed if every detail in every web site out there was handcoded, but as we all know, that’s not the situation. That statement means that every site producing dynamic CSS values from a database, or basically any CMS in general (not that many of them they’re any good, but work with me here… :-)) should use a transitional doctype.

    The perfect solution in those cases would to have a style block at the top of the HTML file and then an id/class connection, or maybe even a dynamically generated CSS file, but in real-life situations of today that’s rarely not the options that are available in most contexts.

    However, the biggest downside about telling people to use a transitional doctype for that fairly minor problem is what Anne was touching on above: rendering modes. I would never use a doctype triggering a less strict rendering mode just because my situation forces me to use an inline style attribute in just one or a couple of cases.

    So, in my humble opinion, the idea is good but I don’t think it works all the way in real world web developing as it is today.

11. Emil Stenström 7 Jun

    11

    @Anne: I believe it is about doctypes still, but that’s another discussion. Good to hear about HTML5, that spec really looks good.

    @Sarven and Ara: I see your point. In my opinion putting style in an attribute inside your structure isn’t enough separation. A <style> should be the least separation requirement.

    @Robert: I didn’t mean that all database driven designs automatically should go transitional. Like Roger suggested, everything that can be done with the style attribute can also be classed and referenced from a style block in the head. That’s a solution for all dynamic designs out there and makes for much better separation.

    Additionally, transitional does not nessesarily force you into a lesser rendering mode, if you use Transitional with an URL you will still get the standards mode rendering across browsers.

12. Robert Nyman 7 Jun

    12

    …everything that can be done with the style attribute can also be classed and referenced from a style block in the head.

    Absolutely, from a CSS perspective. But what I was going for was the perspective of CMS-driven solutions and their likes, the ones we’re currently working with, that don’t offer this support as of today. Real world vs. a protected environment web developing (yes, most CMSs are flawed, but that’s another story…)…

    …transitional does not nessesarily force you into a lesser rendering mode…

    There aren’t just standards mode and quirks mode out there, there’s also something called Almost Standards Mode (please read more in Mozilla’s DOCTYPE sniffing and Activating the Right Layout Mode Using the Doctype Declaration). Basically, what this means is that although you get a somewhat standards mode rendering with a transitional doctype, you will never get the strictest one available.

13. Anne van Kesteren 7 Jun

    13

    Yeah, you should absolutely avoid transitional DOCTYPEs. They are just harmful and encourage you to produce almost standards compliant sites, but not quite as you start relying on specific browser quirks.

14. Johan 7 Jun

    14

    what about inline styles added/removed through DOM scripts?

    Generated code that is

    Most scripts I have seen use styles and not eg classes

15. Emil Stenström 7 Jun

    15

    @Robert and Anne: Good points, we shouldn’t force existing (flawed) CMS:es and the likes into transitional just because the style attribute was a bad idea. But, if style wasn’t in the strict doctype from the beginning, perhaps we would have had less ugly CMS solutions.

    So, it was a mistake adding it but it’s there now and there’s nothing we can do about it. Is that a conclusion you can agree with?

    @Johan: I belive we shoudl add classes to things instead of styling them with inline. Control the design with CSS and the behaviour through JS.

16. Emil Stenström 7 Jun

    16

    Oh and another thing, is “Almost standards mode” that bad? The only difference between that and standards mode is the “layout of images inside table cells” [1], if you avoid that situation you are not relying on bugs.

    (and yes, I need to fix the rendering of blockquotes in comments, thanks Robert :)

17. Johan 7 Jun

    17

    Control the design with CSS and the behaviour through JS.

    I know but using styles or classes does not make that premise any different.

    Problem is multiple classes, if I need to change 1 style at the time I need in analogy 1 class at the time. So i need to remove the last added class to replaced by the new one andf so on.

18. Johan 7 Jun

    18

    … In fact if you mean seperate content and style you have more flexibility with classes.

19. Robert Nyman 7 Jun

    19

    I’m sorry for messing up your comments… :-)

    My take is that (most) CMS vendors wouldn’t have cared if the style attribute was in the specification or not for strict doctypes…

    But basically, yeah. This is the current situation and it’s what we have to deal with.

    Almost Standards Mode is something in Mozilla browsers, but I’m fairly sure Opera has got its interpretation of it and maybe Safari as well. By using a transitional doctype you risk different rendering in different web browsers (when it comes to image aligning in table cell, when using a transitional doctype there will be a different rendering between Mozilla browsers and IE, who has only got quirks and “strict” mode).

    The gist is that using a transitional doctype might be like opening Pandora’s Box, and it’s definitely not worth it for a simple style attribute… :-)

20. Nate 7 Jun

    20

    Again, as I said on Roger’s site - just think about it a little bit. I dynamically create stylesheets with PHP and then use the content-type header of text/css to render the document (or I could do it on the server end and have all css parsed as PHP - either way). This gives me great flexibility. I can declare styles as necessary, and build them on the fly according to info from the database.

    I agree with what both you and Roger are saying on this topic, to me, its no better than using your first example with ‘bgcolor’. It defeats the purpose of true separation.

    I come from a programming background and the MVC design pattern - where there is a separation of my database model, my business logic, and my display. It would be like me adding my logic to the view, simply because it was easier than using the controller file. Overall, in the end, it defeats the whole purpose of separating the three. Same goes with the css, html, js, etc.

21. Emil Stenström 7 Jun

    21

    @Robert Nyman: you’re probably right about the CMS vendors. What annoys me though is that those using only the style attribute for design and can brag about being strictly compliant.

    Concerning almost standards mode, the page you linked to both Mozilla, Opera and Safari have it and they treat it the same way. Since it only affects images inside tables I would say it’s safe to use (Of course we shouldn’t recommend it though).

    @Nate: Yeah, that’s also a good solution… you have to be careful though so you don’t miss out on proper caching, one of the benefits of external CSS files.

    I like the MVC view on things, but I’m sure the people that wrote the specs had that in mind too.

22. Anne van Kesteren 7 Jun

    22

    That page seems incomplete. There are other differences as well. For example, at some point we had special comment parsing only for standards compliant mode because people mess that up all the time. (Now all that is changed, so that is more or less reverted I guess.)

    FWIW, triggering the right layout mode is in my opinion more important than validation. Even if style=”" was disallowed in strict mode you certainly shouldn’t be starting to use a transitional DOCTYPE just to validate.

23. Emil Stenström 8 Jun

    23

    @Anne: Perhaps pull some strings for documentation of the differencies in Opera between the different modes? Could be useful for some.

    About switching to transitional, as I said, I take that back. Even though style=”" should be there it isn’t right now and we have to live with that.

24. Johan 8 Jun

    24

    http://www.quirksmode.org/blog/archives/2005/07/benchmark_tests.html

25. Johan 8 Jun

    25

    My end conclusion is styles
    can be useful to change the appearance of a element when using JS/DOM to do that. In the quirksmode article it states that using styles on heavy scripts that class is faster. But for one simple element, I dont see the advantage of using classes. This is not all of course …

    For styling an element (static) by using only HTML and the CSS to style it. Of course, styles are not used often. Thought to make one change in a page, it is extremely handy. You dont have to create an extra class for just implementing one style.

    Doctypes that use the strict doctype are better coding practices to make the layout work crossbrowser and futureproof.

    But if you need to use depreciated elements, you cannot use strict since it wont validate.

    I think it is very important to go further the standard way but you also have to take in account the past which is transitional or styles. Not everyone codes the same way.

26. Andrew Vit 8 Jun

    26

    Without inline styles, how else would you override a stylesheet’s class/id styles using JavaScript to create behaviour on elements? You still need a way to set attributes on an element directly, whether the inline style is spelled out in the source HTML or created dynamically.
    Also, sometimes the style is actually the content. Semantically, if you are presenting color swatches, the content is the color: it should not be defined anywhere else but directly on the element of the content.
    Also, in some cases you may need to style something which is a one-off unique element that cannot be classified or otherwise has no reason to be identified except for some very local stylistic reason. Trust me, clients are like that sometimes… Not having inline styles would require us to identify these elements and create separate style definitions for them when all we actually want to do is break out of the norm for one specific case.
    Regardless of doctype, inline styles are quite necessary. The fact that the styles are formalized into a single style attribute without separate color/align/bgcolor attributes is really what makes it “strict” in my opinion.

27. trovster 8 Jun

    27

    Andrew, you shouldn’t add style attributes with JavaScript, you’re then mixing style and behaviour. Instead, you should add classes/ids and reference them in the stylesheet. Not ideal in a few cases, but the majority of the time that’s the best solution.

28. Emil Stenström 8 Jun

    28

    @Johan: the benefit of not using style=”" is separation. If we start recommening that for single changes (to the DOM or directly) we could as well suggest bgcolor or something similar.

    Also, “handy” shouldn’t be an argument for it: tables are indeed handy for equal height columns but we still work hard to use CSS instead.

    @Andrew: I agree with trovster here, adding style from javascript is no better than mixing content and design. Switch between states with classes instead.

    Your example with color swatches is an interesting one and so are all examples where the design is acctualy the content. I’m not sure how to handle that, perhaps style has use in that case… You could of course use an image then (in the colro swatches case a php script could use GD to make a 1px thing).

    For one-off cases you simply use a style block on your head where you define your style. That way it’s still separated from the content. I do not believe style=”" is separated, attributes apply to the element they are inside and that’s where the separation breaks.

29. sunshine 10 Jun

    29

    I agree with Andrew and Anne. I understand the argument but from a objects point of view…

    (x)html elements can have style (unlike xml), therefore (x)html elements should have a style attribute).

    If not then we get class names like “blueborder” or “superbold” for those semi-rare (unless you work with my clients) but existing instances where you want to apply style completely arbitrarily and there is no good structure descriptor.

    It seems that html elements may not be purely structural just because they can “own” style… heck they are styled by default. Yes people should use the style attribute wisely but I don’t believe it should be removed it from the spec.

30. sunshine 10 Jun

    30

    Also it’s a slippery slope to say that style might as well be bgcolor. There will always be better ways to do something that still may not be perfect. style is more seperation than bgcolor because all of the visual stuff is confined to one uniform attribute. Complete seperation, as I mentioned before doesn’t seem to be something html specs can aim for.. that’s why we have xml

    Also I apologize for not closing my tag. Could you fix it for me? :)

31. Emil Stenström 10 Jun

    31

    @sunshine: I belive we are moving in the direction of complete separation. WIth CSS3 we will no longer have to use many of the classnames we push in today. The style attribute might be convienient for a few cases, but then you move away from the separation strict is all about.

    Being able to move a customers idea of what a page looks like to code should be a programming issue the CMS solves, not something you use markup for.

32. Paul 15 Jun

    32

    Honestly, sometimes it’s not feasible to switch out the doctype on a single page of a large database driven site. I think that inline styles are perfectly valid in a strict doctype. They still conform to all the rules of CSS and can be overridden from a global stylesheet by an “!important” delcaration, or by a rule which exceeds the inline style’s specificity. A sledgehammer is still a tool and still has its purpose. I think inline styles are an example of what happens when theory hits the pavement, so to speak. ;)

33. Matthew Brundage 16 Jun

    33

    Remember that the word “cascading” appears in “CSS”. Inline styles, while not esthetically pleasing, nevertheless allow for economy of code.

    If, for instance, you implement a style that appears only once on only one page, than an inline style makes sense. Or, if you find yourself implementing that style in multiple areas of your site, then by all means, place it in an external document.

    The beauty of CASCADING style sheets is that a style can be implemented on a single tag, a single page, or multiple sites, depending on your desired level of specificity.

34. Andrew Vit 19 Jun

    34

    Regarding: “I agree with trovster here, adding style from javascript is no better than mixing content and design. Switch between states with classes instead.”
    How would you then position elements on top of a base layer, say like Google Maps? Or make elements draggable? You would really make a new class for each possible coordinate? No…
    Please keep in mind that there exist websites that aren’t blogs, where everything is classifiable!

35. Emil Stenström 19 Jun

    35

    @Paul: I belive that it’s a tool that destroys what strict is trying to accomplish. It _is_ valid right now, but should it?

    @Matthew Brundage: That exact argument can be applied to using tables for layout once on a page. Economy of code is not all that’s important. You can still apply style to an element without the style attrib.

36. Justin Perkins 22 Jun

    36

    This is an arguement for purists/philosophers.

    Tell me how to do this without inline styles and I’ll bow down…

    importance = 10
    em”>Inline Styles

    *There is no limit to how important something can be in the above example.

37. Justin Perkins 22 Jun

    37

    That didn’t render too well, but it’s not important anyway. I know you purists are just going to suggest I use dynamic styles and place them in the head of the document. I’m sorry but that’s simply quite impractical. That sounds as silly as not including target attributes in your markup so you can validate, only to use JavaScript to add them back.

    As for the arguement that JavaScript should not be changes the style attribute of an elment, and instead change a class…

    Please explain how this would work with one of the many effects libraries, like Scriptaculous or Rico?

38. Emil Stenström 22 Jun

    38

    @Justin Perkins: Just to get that out of the way, you shouldn’t open new windows. If the user is skilled enough to want it, he will know how to open them. Easy as that and no javascript or target needed.

    I’m guessing you want to add lots of levels of importance to your code, things like a tag cloud? Right? That’s dynamic CSS right there which means it’s as much work writing it to a CSS class as writing it inline. I perfer not polluting my structure with style.

39. Justin Perkins 23 Jun

    39

    > Just to get that out of the way, you shouldn’t open new windows. If the user is skilled enough to want it, he will know how to open them.

    Ok, but I’m just trying to equate the anti-new window argument to the anti-inline style one. I think they are very similar, philosophically speaking.

    So, we’re talking tag clounds (ala Flickr vs. Technorati). If I want to implement a tag cloud like Flickr does (imo is the *proper* way to do it), what’s the cost of doing it the dynamic CSS class way vs. inline styles. Is it worth it (not just to you, but to whoever you are billing/working for)?

    > That’s dynamic CSS right there which means it’s as much work writing it to a CSS class as writing it inline

    I’m not buying that argument. Every one of your views (a purist like you has to be MVC right?) is passing up dynamic CSS to be stuffed into the document head? Talk about muddling up the code!

    I don’t see how this:
    I love inline styles

    Is worse than this:
    
I hate inline styles

    In fact, that is just too ludicrous to even insinuate.

40. Justin Perkins 23 Jun

    40

    Sorry, that really sucked.

    I posted what I was trying to say on my site if you want to see what I so poorly tried to explain.

41. Emil Stenström 23 Jun

    41

    @Justin Perkins: Of course I see your point too. Using inline styles is easier and there are places where it makes sense.

    I would implement a tagcloud by picking 10 font-sizes (users won’t notice the difference of 100 different levels) and make a class for each one of them. Then set the size for each tag to one of the above.

    Let’s just agree to disagree on that one.

42. Justin Perkins 23 Jun

    42

    I’m with you on that one Emil, great discussion you promoted here :)

43. Pozycjonowanie 20 Oct

    43

    Max, you shouldn’t add style attributes with JavaScript, you’re then mixing style and behaviour. Instead, you should add classes/ids and reference them in the stylesheet. Not ideal in a few cases, but the majority of the time that’s the best solution.

44. Jeremy Nicoll 23 Dec

    44

    The strict doctype has no relation to whether inline styles are used or not. The main idea of CSS is to separate content and styling, and so inline styling is discouraged - but this is something that CSS experts generally encourage and has nothing to do with doctypes. In strict mode, inline styling is perfectly valid as style is a valid property of most objects. The only time that I ever use inline styling is when I am applying a style to an element that I am only going to use once. Why clutter up my CSS file with something that is only going to be used once?

45. Emil Stenström 23 Dec

    45

    @Jeremy Nicoll: The relation is clear, whether you choose to see it or not. Doctypes define what elements and attributes are allowed in a document. It could therefore disallow the style attribute…

    Why you shouldn’t be allowed to use it “only once”? Because once rarely stay once when you deal with real world websites. If you’ve allowed one step away from the content/style separation you’ll easily do more of them.

46. Sean Fraser 12 Jan

    46

    When I read this in May I nodded and thought how true. Inline styles in Strict should not be done. However. I’ve recently had the pleasure of working on a Strict site where I was not allowed to touch the style sheets but given access to the products’ HTML content. [Styles sheets were in the CMS of the design agency; product pages were client accessible. Don't ask.] I used inline styles for new HTML elements. A real world website, indeed.

47. Emil Stenström 12 Jan

    47

    @Sean Fraser: I’ve done that too, real world projects sometimes require you to work with only inline styles. Thing is, the html of those sites are so bad it’s just silly calling them valid anything. You’re in there really mixing style and content in worse ways than we did in 1996!

    I’ve done the same, but I don’t think that’s an argument against removing it.

48. Sean Fraser 13 Jan

    48

    Emil: I agree: inline styles should not be allowed in Strict documents. I found twisted irony in my having to do so.

49. mogens overbeck 19 May

    49

    In my view inline styles *are* actually a good thing, since you can use them during the initial markup phase - that’s often the way I do it, anyway. I mark up, styling as I go, and in the end transfer the css to an external stylesheet, so for me it’s just a handy way of speeding up the workflow. I see your point though, if it wasn’t allowed, people would be forced to learn better development practices, but I’m not sure I agree that’s the way to go about it :o)

If you want to you can follow the disussion through a comment feed.