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.

69 responses to “Inline CSS should not be allowed in strict doctypes

  1. 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. 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. @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. 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. @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. 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. @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. Pingback: 456 Berea Street
  9. 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.

  10. 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’.

  11. 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.

  12. Pingback: Why is the style attribute allowed in strict doctypes?
  13. @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

    &lt;style&gt;

    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.

  14. …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.

  15. 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.

  16. what about inline styles added/removed through DOM scripts?

    Generated code that is

    Most scripts I have seen use styles and not eg classes

  17. @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.

  18. 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 :)

  19. 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.

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

  21. 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… :-)

  22. 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.

  23. @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.

  24. 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.

  25. @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.

  26. 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.

  27. 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.

  28. 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.

  29. @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.

  30. 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.

  31. 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? :)

  32. @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.

  33. 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. ;)

  34. 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.

  35. 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!

  36. @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.

  37. 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.

  38. 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?

  39. @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.

  40. > 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:

    <em>I love inline styles</em>

    Is worse than this:

    <em>I hate inline styles</em>

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

  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. 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.

  43. 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?

  44. @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.

  45. 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.

  46. @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.

  47. 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)

  48. This is interesting article, I did not it think that it yes. Interesting it knew persons about this how much. Sorry if I wrote bad there now my English is novice and I do not it write yet good.

  49. Hello Emil,

    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

  50. @Alex Design: Not much have changed when it comes to CSS in the latest version of Firefox. My best bet is that you have an error there somewhere, and the best way to figure that out is to simply move out all your CSS to an external file and validate it. Annoying, but something really should do.

  51. No offense to the author, but frankly I LOVE inline styling.
    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.

  52. “Why should you want to include design information inside of a document that you just explicitly stated would separate the two?”
    =============================================
    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

  53. “What annoys me though is that those using only the style attribute for design and can brag about being strictly compliant.”
    =============================
    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.

  54. @Wm Tipton: I guess I struck a nerve there. Thing is, the whole idea of strict compliance is to encourage people to remove all stying properties from the HTML. It is, you can go read the spec to confirm it.

    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.

  55. There is nothing wrong with inline, and there is a good reason to use CSS. Firstly, we do all this separation so that screen readers only read content instead of style. Also, if you style with css and the reader is visually impaired, their own setup will adjust the css accordingly.

    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.

  56. “@Wm Tipton: I guess I struck a nerve there. Thing is, the whole idea of strict compliance is to encourage people to remove all stying properties from the HTML. It is, you can go read the spec to confirm it.
    ==============================================

    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

  57. “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

  58. “I perfer not polluting my structure with style.”
    =====================================
    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 :-)

Comments are closed.