Inline CSS should not be allowed in strict doctypes
As many of my readers already know all pages should include a doctype. The doctype tells the browser (or other user agent) what kind of document it can expect and what standards it follows.
You can divide doctypes into two categories. The first category consist of the transitional ones, the ones that allow old syntax and still validate, and the other one consist of the strict ones. I have repeatedly recommended the strict versions for a simple reason: it's the best ones for separating design from content.
Just to show an example, transitional allows the following:
<body bgcolor="blue">
<center>
Strict, by its very nature, requires the use of CSS instead.
What I find strange is that inline CSS is valid in strict. Inline CSS is when you use the style
attribute to set design information inside of the HTML. As an example the two deprecated pieces of code above can be done with:
<body style="background: blue">
<div style="text-align: center">
How is that any better than the transitional versions? Inline CSS goes against all the logic involved in the idea of two distinct doctypes. Why should you want to include design information inside of a document that you just explicitly stated would separate the two?
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.
Strict doctypes are for documents where the webmaster has taken the time to clearly separate the content from the design, not other hybrids.
Comments
By: Sarven Capadisli (#1)
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.
By: Dennis (#2)
By: Emil Stenström (#3)
By: Ara Pehlivanian (#4)
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).
By: Emil Stenström (#5)
Like you say, most of the problems can be solved with a dynamic CSS-file, that is, dynamic design instead of dynamic content.
By: karl (#6)
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. :)
By: Emil Stenström (#7)
By: Anne van Kesteren (#8)
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.
By: Sarven Capadisli (#9)
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'.
By: Are inline styles bad? | ara pehlivanian—Web Standards, Web Culture, Web Everything.™ (#10)
By: Robert Nyman (#11)
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.
By: Emil Stenström (#12)
@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.
By: Robert Nyman (#13)
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...)...
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.
By: Anne van Kesteren (#14)
By: Johan (#15)
Generated code that is
Most scripts I have seen use styles and not eg classes
By: Emil Stenström (#16)
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.
By: Emil Stenström (#17)
(and yes, I need to fix the rendering of blockquotes in comments, thanks Robert :)
By: Johan (#18)
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.
By: Johan (#19)
By: Robert Nyman (#20)
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... :-)By: Nate (#21)
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.
By: Emil Stenström (#22)
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.
By: Anne van Kesteren (#23)
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.
By: Emil Stenström (#24)
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.
By: Johan (#25)
By: Johan (#26)
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.
By: Andrew Vit (#27)
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.
By: trovster (#28)
By: Emil Stenström (#29)
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.
By: sunshine (#30)
(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.
By: sunshine (#31)
Also I apologize for not closing my tag. Could you fix it for me? :)
By: Emil Stenström (#32)
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.
By: Paul (#33)
By: Matthew Brundage (#34)
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.
By: Andrew Vit (#35)
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!
By: Emil Stenström (#36)
@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.
By: Max Design - standards based web design, development and training » Blog Archive » Some links for light reading (23/6/06) (#37)
By: Justin Perkins (#38)
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.
By: Justin Perkins (#39)
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?
By: Emil Stenström (#40)
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.
By: Justin Perkins (#41)
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.
By: Justin Perkins (#42)
I posted what I was trying to say on my site if you want to see what I so poorly tried to explain.
By: Emil Stenström (#43)
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.
By: Justin Perkins (#44)
By: About Web Designing » Blog Archive » Inline CSS should not be allowed in strict doctypes (#45)
By: Esqueça o atributo style. Estilos inline em doctype strict são resquícios do câncer de um passado sem padrões. » Revolução Etc - Web Standards em uma casca de noz! (#46)
By: Pozycjonowanie (#47)
By: Jeremy Nicoll (#48)
By: Emil Stenström (#49)
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.
By: Sean Fraser (#50)
By: Emil Stenström (#51)
I've done the same, but I don't think that's an argument against removing it.
By: Sean Fraser (#52)
By: mogens overbeck (#53)
By: prezenty (#54)
By: Alex Design (#55)
I'm sorry for digging up this old post but after the release of Firefox 3.5.2 i have a bunch of problems with the inline CSS.
First of all i have to say that i don't have as much experience as many designers do, but i give my best to acomplish my projects. The reason why i'm writing this comment is that after the release of the new Firefox version a project of mine shows completely different. It's like the inline CSS is ignored or something like this. I wrote an e-mail to firefox with this problem but i didn't got any reply.
I hope you can help me in this matter because i have no more options.
Best regards,
Alex
By: Emil Stenström (#56)
By: Alex (#57)
By: Oyunlar (#58)
By: Wm Tipton (#59)
I use pretty much all 3 types of styling, a external, internal and inline, but I use inline more time than not because I like to make each page...and each part of a page...unique...and I dont want to have to keep checking back to another style sheet file to do it.
If they ever do away with inline styling, Im going back to using cheap software to build my websites.
By: Wm Tipton (#60)
=============================================
Youre forgetting, friend, that NOT ALL of us WANT to do away with even HTML 'styling'.
I like CSS much better, so Im fine with it as long as I have an alternative, but I frankly like being able to style on the fly and not having to keep referring back to another huge css file trying to track down where a specific part of the code is in that file.
I prefer having the style code right there on the page Im working on.
I use a style.css file typically for things that will be used on EVERY page...such as backgrounds, page width and such and such.
When it comes to the individual page I like having the css ON the page itself.
I dont get bent out of shape or write negative articles about people who dont do it the way I do...and I really dont think anyone should waste their time worrying about how *I* do it...know what I mean ?
wm
By: Wm Tipton (#61)
=============================
Dear God man...what difference does it make to YOU ?
I mean really. Is your life any worse off ?
I honestly think we need to find a hobby or something when I see this sort of complaint.
By: Emil Stenström (#62)
So, if the whole idea is to promote external stylesheets, why do people that don't abide to that idea get to be compliant?
This is not about what I like and not, it's about what the spec says. If there was a "Blue compliant mode", I wouldn't say that red pages where valid blue.
By: martin (#63)
Inline or external makes absolutely no odds to this. External is useful if you want to use the same styles on multiple pages. Inline is essential for unique pages because you don't want to be drawing in several style sheets when you can do everything on that one page and you definitely don't want to cloud up your general styles with hundreds of styles that are only used once or twice around your many pages.
By: Wm Tipton (#64)
==============================================
And it IS removed from the 'HTML' in that HTML wont be doing the styling. Seems simple enough.
What I dont like is for someone who doesnt USE something to say that the REST of us should be deprived of it as well.
I ONLY use an External CSS file for CSS that will apply to MORE than one page. I also use Server Side includes where I have code that will also do the same.
But about 80% of my coding is very much element oriented and to be robbed of inline styling because someone else doesnt like it is, well, communism at its finest. Why dont we just start burning books that the rest of us read if YOU dont personally like them ?
Having three options for CCS styling means YOU dont have to EVER use inline if YOU dont personally like it. That goes for the rest who dont either. I respect that.
But its NOT right for you to bash inline simply because YOU dont use it or like it....even if you hate it, its irrelevant because no one is FORCING you to use it...kwim ?
The whole idea clearly is to use External style sheets where they are LOGICAL....not where they are not.
I dont want a 100,000 line stylesheet with styling it it for every single element in my entire website.
MOST of my sites use position:relative for my wrapper/container with a LOT of elements being position:absolute within that container.
I DO NOT want to have to keep jumping back and forth between my page and a css file trying to track down EVERY SINGLE element in that huge file.
When its done how *I* do my sites inline is the ONLY way to go...I know because Ive tried it both ways and it gets bad really quickly once a few hundred absolutely positioned elements are on the site.
On my sites where an element is exactly the same every time (rarely happens except for header and navigation on my websites) then I toss that stuff into an external CSS file.
But that simply isnt much at all and its far easier for me to use SSI's for my navigation to begin with.
If they take away inline styling, I'll go back to using crap software to design my websites or I'll just stop designing websites altogether.
Those of you who want to get rid of inline are simply thinking of YOUR manner of site design. You arent taking into account that there are a LOT Of us here who dont do it the way you do.
wm 33953 65 Wm Tipton 0 http://web77.org 2010-07-03 03:07:18 Inline or external makes absolutely no odds to this. External is useful if you want to use the same styles on multiple pages. Inline is essential for unique pages because you don’t want to be drawing in several style sheets when you can do everything on that one page and you definitely don’t want to cloud up your general styles with hundreds of styles that are only used once or twice around your many pages.
================================================
EXACTLY !
MOST of my webpages (I do webmastering for others also) require that I use quite a bit of absolute positioning for a lot of elements on the page.
For instance a guy wants a image bumped up 4 pixels and to the right 10 pixels. Well that used to throw something else out of place and so eventually I got smart and just started using the relative position for the container and absolute for elements. So now if I need to bump something nothing else is affected and I can overlap images too, which is something this one client likes as well for some of his pages.
Before everything on the page had to fall where it wanted to. I had a little bit of room for play, but now by using the inline relative/absolute styling I have absolute control over everything on my pages right down to the pixel.
But it requires that every element be positioned individually and that is a LOT of elements to be putting into a separate CSS file that I was driving myself insane with hopping back and forth and then sometimes changing the wrong thing and having to change it again.
With inline I know EXACTLY which element is being affected...theres no way to be wrong and I dont have to scroll thru hundreds and thousands of lines of styling to find the one Im looking for....its right there on the page itself.
This really is a no brainer.
Those who dont like inline...DONT USE IT :-)
Those who absolutely require it...like me...just use it and not say a word about it to anyone....
wm
By: Wm Tipton (#65)
=====================================
And that is your prerogative. No one has any business judging your decision in the matter AS LONG AS you are not judging anyone else.
CSS removes the need for HTML styling. We simply have more than one option for using CSS on a web page.
If you dont personally like having styling within your HTML, that is great....more power to ya. But you shouldnt be allowed to speak for those of use who DO want to use inline styling....kwim ?
And my question is....HOW are YOU affected if *I* use inline styling ?
If you are browsing my sites either way the styling is going to have the same effect in the browser whether its inline or external. The viewer isnt going to know the difference and doesnt need to concern themselves with it.
Ill be honest here and I mean no offense, but to me this seems to be a topic for geeks to have something to complain about. There is no honest reason for anyone who doesnt like inline styling and doesnt use it to whine about it....no VALID reason whatsoever.
If we just admit this fact maybe we can move on and all get along :-)