Subscribe via RSS

Can XHTML Strict Ever Be A Practical Standard?

Filed Under Usability

Whenever possible my web applications comply to the XHTML Strict standard; however, the ever growing want for Web 2.0 mashup applications forces developers to create content for multiple platforms such as PDAs, RSS readers, and multiple web browsers. It pains me when I need to enforce styles across platforms thus forcing me to downgrade from Strict to Transitional.

For example, in a recent post I included a picture of a baby duck wearing glasses. In my layout I wanted it to float right. Easy enough, I just place a class on it and define my style in the CSS. It looks great on the page and is Strict compliant, but then it renders incorrectly in feed readers such as Google Reader.

Feed reader differences

In this example, I don’t give a hoot how the baby duck renders in Google Reader, but what if I did? I would be reduced to make the following change:

<img src="…" class="right" />

changed to

<img src="…" style="float:right;" />

As a result, this is not XHTML Strict complaint and I would have to mark the entire page Transitional. Perhaps this sounds silly, but as data is passed more freely between multiple systems this problem will only get worse. As a result a decision must be made between two choices:

  • Keep data and display decoupled, but surrender render details on other systems
  • Embed styles and render how you want, but surrender decoupling

Does it need to be this black and white? Can a happy medium be meet with a new standard? For example, what would happen if the next version of RSS allowed you to add the location of an associated CSS file? Would this solve the problem or would it create more problems?

Shout back…

RSS Icon

  Don't miss a drop! Subscribe now via RSS or email.


8 Responses to “Can XHTML Strict Ever Be A Practical Standard?”

  1. Justin Barta on August 10th, 2007 8:51 am

    Technically, inline styles are XHTML strict compliant (assuming you write the attribute in lowercase letters and enclose the value in quotation marks). So, in your code example, I don’t believe you would need to downgrade to the transitional DTD. Although the use of inline styles is a poor coding practice, code with properly formed style attributes will validate as XHTML strict.

    Here is an article discussing why the style attribute is allowed (and maybe why it shouldn’t be):

    Another instance where XHTML strict is extremely difficult to achieve is in HTML-based email messages. It is nearly impossible to control the appearance from one HTML-supporting email client to another, much less write XHTML strict to do it.

  2. Max Pool on August 10th, 2007 9:33 am

    Justin – Good points and a great article.

    I concede that according to the DTD you are technically correct. But should the style be allowed on XHTML Strict?

    For that matter, even tags like <em> are used for display logic. Should they even be allowed in a proposed ‘strict’ separation of markup and presentation?

  3. Justin Barta on August 10th, 2007 10:58 am


    I think that eventually all presentation/formatting elements and attributes should be weeded out of the strict definition. I also think that web standards are relatively young and therefore today’s XHTML “strict” is in an, ironically, transitional phase. Most web developers aren’t even implementing standards based practices at this point.

    In the future, you can expect to see a revised strict DTD that is indeed strict.

  4. Jason Gibb on August 10th, 2007 8:52 pm

    Max, I had to read this a couple of times because I was a little confused at first. To me this issue seems more a problem of lack of support for external stylesheets in certain clients or protocols, not an issue with XHTML Strict. If other systems mess up rendering your content, it’s their problem for not fully supporting well-documented standards that have been around for a long time. On the other side of the coin, we shouldn’t be so married to our beautiful designs that we can’t allow a client to render the content in whatever way is most appropriate for the device. That’s why we separate content and presentation in the first place.

  5. Matthew Minix on August 12th, 2007 10:40 am

    The irony to me is, the reason they’re trying to make things more strict is so that it’s easier for software manufacturers to pull in information, and so they don’t need to prepare for a bunch of different rules. For anyone who’s ever tried to build a DOM Parser (or similar application), you know one of the most annoying parts is connecting the nodes to their appropriate styles.

    You need to search for the stylesheet(s), figure out it’s absolute/relative position on the server, Find the class, (or id, or selector or whatever) as well as find every other rule that may or may not be applied to it (on the may not, only to see if something else is overwriting it) Then you have to see if any active Javascript is or will overwrite it, (depending on what point you’re running it, server side or client side), which is so annoying I ignored the step for a long time.

    A lot of people want these additions to CSS, and now there’s a lot of talk about variables, and that’s great, but when the additions are made, someone approving them needs to make it so that we don’t need to add in all of these different checks, otherwise the point of XHTML has failed.

  6. Max Pool on August 12th, 2007 5:19 pm

    Hmmm…after reading Matthew’s comment I am starting to think that an idea such as external style sheets being applied within other applications (such as Google Reader) is a bad idea.

    Personally, if I had to create a simple application that used syndicated content, I would not be crazy about having to parse CSS and DOM elements as Matthew says.

    YouTube has found that people will sacrifice some quality for high availability. This may be no different that RSS, so who cares how it renders…

  7. Jason on August 14th, 2007 1:24 pm

    Don’t worry about it.

    (X)HTML isn’t what it’s cracked up to be anyway. (the strict or transitional variety). Browsers are hacked to treat XHTML as HTML anyway unless you’re serving your pages with a “application/xhtml+xml” MIME type – which doesn’t work in IE. What it really comes down to, is your beautifully validated XHTML pages are really invalid HTML pages.

    I say screw it, sometimes I find myself creating (X)HTML pages out of habit because I used to think it was somehow ‘better’, but why? It’s silly, and more and more people are abandoning that path everyday. The XHTML 2.0 camp seems to be slowly losing more and more mindshare to the HTML 5.0 camp everyday.

  8. Swistak on February 11th, 2008 6:17 pm

    Well, first of all – i understand you zealots – but come on – do you have ANY real life expirience – seriously – read ANY optimization faq – and you’ll find that your beatifull concepts don’t work in real life – you have to apply styles – sometimes dynamically, sometimes you need exactly one row to be noted diffirently – you’ll create css class for that? and generate all that css servers side dynamically ? good luck with that – it’ll do wonders for your webhost.

    Also did you know that using @include causes browsers to not cache css ? oh and there’s more – sometimes css ARE cached – even if you try to change them (that’s why some frameworks add random strings after “?” to force browsers to reload css) but guess what? now EACH request loads 10-20 times slower then it used to …

    anyway … complaining that your website isn’t “Strict” even if it’s, or it’s ugly … is welll kinda stupid and masochistic for me

Max Pool - © 2024 - {codesqueeze}. Sycorr Banking Solutions