Emil Stenström: Why XHTML is a bad idea
In Why XHTML is a bad idea, Emil Stronhom of Friendly Bit makes a good case against XHTML being seen as a replacement for HTML. The additional strictness moves the burden of error correction to every author using markup on the planet, making the web impossible for people without an unhealthy amount of markup knowledge to participate.
It's much more practical for errors to handled by a few well-funded browser manufacturers, especially since they already have sophisticated error handling. HTML5 is defining error handling for HTML parsers, as well as for MIME types and suchlike. This will mean websites can be highly interoperable even if their code isn't perfect; which is good news for all those amateurs blogging and reading on the web.
Interestingly, it's the lack of standards compliance in CSS which causes almost all interoperability problems. It's rare to find a website break because of its markup, unless you use a 20th century mobile phone.
Last edited by Ben Millard on 29 Aug 2006 06:55 pm; edited 1 time in total
Share: 
I've generally been of the view that a UA's forgiving attitude to error tolerance of cruddy, amateurish code is a good thing (even if not so handy for dedicated web developers), so long as the UA actually knows how to handle compliant code correctly when it encounters it.
Combine IE's ability to make sense of bad code with Moz's attitude to standards support and a UA would really be offering the best of both worlds, imho.
That said, I don't see this as strictly being a problem with X(HT)ML.
It's unlikely that amateurs and hobbyists are going to stray into using an XML-based mime-type.
Only those with a mind to 'professionalism' and web standards are likely even to enter or trigger an XML environment which is so intolerant towards errors.
Share:
| Cerbera wrote: |
| Emil Stronhom |
Simon Pieters
Share:
| Cerbera wrote: |
| In Why XHTML is a bad idea, Emil Stronhom of Friendly Bit makes a good case against XHTML being seen as a replacement for HTML. |
It's a border-line rant in my opinion, and adds nothing of any value to the ongoing debate - except to add another voice to the anti-XHTML bandwagon. That's just my opinion of course.
| Cerbera wrote: |
| The additional strictness moves the burden of error correction to every author using markup on the planet, making the web impossible for people without an unhealthy amount of markup knowledge to participate. |
I don't agree. The difference between HTML and XML compliant XHTML is not a huge barrier in my opinion. What is a major pain is content negotiation, especially when there are no discernible benefits to the individual producing the content. Blame Microsoft, not XHTML.
| Cerbera wrote: |
| It's much more practical for errors to handled by a few well-funded browser manufacturers, especially since they already have sophisticated error handling. |
Why not move this burden on to the authoring tools? That seems to me a much more logical approach and, I would've thought, a great deal easier.
| Cerbera wrote: |
| Interestingly, it's the lack of standards compliance in CSS which causes almost all interoperability problems. It's rare to find a website break because of its markup, unless you use a 20th century mobile phone. |
Could you point me in the direction of any supporting research, or is this purely anecdotal? I know next to nothing about HTML parsers, but it seems to me that you can't completely separate the application of style rules from parsing the underlying mark-up i.e. broken mark-up makes for broken CSS. It's always been my assumption that XHTML, in addition to allowing for greater efficiency and accuracy in parsing (with all the benefits that this entails), would also make the application of CSS less error prone. I'd welcome any corrections on that score from those in the know.
Share:
| Torsten wrote: |
| It's a border-line rant in my opinion, and adds nothing of any value to the ongoing debate - except to add another voice to the anti-XHTML bandwagon. That's just my opinion of course. |
I agree with you somewhat. Most of the reasons stated by the author were complications in the development arena. He even finishes the article with a paragraph about 'XHTML being difficult for beginners'. So are most things until you have learnt how to do them (and continue showing an interest to learn about the subject).
| Torsten wrote: | ||
Could you point me in the direction of any supporting research, or is this purely anecdotal? I know next to nothing about HTML parsers, but it seems to me that you can't completely separate the application of style rules from parsing the underlying mark-up i.e. broken mark-up makes for broken CSS. It's always been my assumption that XHTML, in addition to allowing for greater efficiency and accuracy in parsing (with all the benefits that this entails), would also make the application of CSS less error prone. I'd welcome any corrections on that score from those in the know. |
If the XHTML markup is invalid, then most UAs that I can think of will display the content with little or no problem, so long as there is no styling that is affected by the errors and the document is text/html. If the CSS hasn't been tested across UAs, then whilst the XHTML can be perfectly valid, the CSS can easily break the site. This what I took Cerbera to mean by the lack of compliance with regards to CSS.
Cez
Share:
| cez wrote: |
| If the XHTML markup is invalid, then most UAs that I can think of will display the content with little or no problem, so long as there is no styling that is affected by the errors and the document is text/html. If the CSS hasn't been tested across UAs, then whilst the XHTML can be perfectly valid, the CSS can easily break the site. This what I took Cerbera to mean by the lack of compliance with regards to CSS. |
(my emphasis)
Sure, that goes without saying. My point is that you can't look at the mark-up and CSS in isolation.
If my understanding of the way browsers work is anywhere near accurate, and there's every chance that it isn't, then broken HTML must be at least partly responsible for some CSS rendering problems. One immediately obvious reason for this is that each browser will use their own error detection and correction heuristics to correct the mark-up errors before applying style rules. XHTML should fix this problem, and in doing so make cross browser CSS more reliable.
I confess I'm playing devil's advocate here. I don't hold any particularly strong views one way or the other to be honest, though I generally consider XHTML to be a good thing. Whether or not the ideals that XHTML set out to attain can ever be reached is another matter. Time will tell, though it'll clearly never happen if developers are unduly influenced by the backlash - unjustified in my opinion - that we're now seeing from some quarters.
Share:
CSS has got nothing to do with interoperability; CSS is design, and design doesn't matter in interoperability terms - what matters is data, and XHTML is data - that's why it's important that it should be valid; it's the only validation that does matter.
What if XML parsers were all loose? What then would be the value of XML?
None at all - XML is its validity; without that it's nothing. XHTML is a reformulation of HTML as XML, because HTML is not strict enough to ensure good interoperability within a simple set of parsing rules.
In any case, this guy doesn't seem to be arguing XHTML vs HTML at all - he's just arguing "strict coding" versus "slack coding", and his only real point is that slack coding is easier.
Well tough! Professional catering is easier if you don't have to think about all that annoying health and hygiene legislation! The rules are there to provide an even baseline for everyone - if we follow his line of argument we'll just have de-facto standards determined by the strongest commercial forces (ie. what we have now taken to its extreme!)
Share:
| brothercake wrote: |
| If we follow his line of argument we'll just have de-facto standards determined by the strongest commercial forces (ie. what we have now taken to its extreme!) |
You see this sort of argument from a lot of (anti-CSS) proponents of tables for layout: "I think the W3C standards suck, they're all a bunch of fascists anyway. I've got a set of standards that I work by and I think they should be the standard."
They don't seem to recognise the parallel with just about every other industry on the planet that has codified standards.
Share:
The W3C does suck! But that's not the point either 
The value of standards goes way beyond individual standards/bodies themselves.
Indeed, X/HTML in particular is rather stagnant, and HTML 5 suggests a lot of interesting and useful stuff, which the W3C would do well to listen to.
But in the meantime, the fact that standards are imperfect is not a reason for abandoning them in favour of whatever suits us individually at the time. That way lies chaos.
Share:
| brothercake wrote: |
| But in the meantime, the fact that standards are imperfect is not a reason for abandoning them in favour of whatever suits us individually at the time. That way lies chaos. |
Agreed. Professionals should use strict standards and not just for the reasons given here. Standardised code/markup makes it easier for other coders to update. I hated having to updating other people’s spaghetti table layouts with font tags etc... - don’t you?
It is said and I had in the past believed for a long time that every day people should also be able to use crap markup to publish a website however do they really need to anymore? With the amount of free tools out there including Blogs and Microsoft Word it should be down to the authoring tools to code/markup (and yeah comply with standards) and every day people can stay away from markup.
| brothercake wrote: |
| ...and HTML 5 suggests a lot of interesting and useful stuff, which the W3C would do well to listen to. |
Do you think they would implement my date tag idea...
<date country="uk">1/3/2003</date>
<date country="us">3/1/2003</date>
Johan De Silva / Portfolio
Share:
| Johan007 wrote: |
| With the amount of free tools out there including Blogs and Microsoft Word it should be down to the authoring tools to code/markup (and yeah comply with standards) and every day people can stay away from markup.
|
Agreed, but as an authoring tool company it's a big ask in development terms. One thing that would help out all AT companies is for DHTML editable mode to enfore strict mark-up according to set DTD.
| Quote: |
|
<date country="uk">1/3/2003</date> <date country="us">3/1/2003</date> |
I prefer the Microformats approach to run within XML date types:
| Code: |
| <abbr class="dtstart" title="1998-03-12T08:30:00-05:00"> |
Share:
Brothercake, I think you've got the wrong end of the stick. The article is arguing against the apparent desire of some W3C members to create a new web (3.0?) which would only permit XML. He is objecting to throwing HTML in the bin and making it mandatory for every page to only use XML, and for every browser to only accept XML. I also object to that desire.
Share:
Ben,
How about a halfway house that all XHTML served with the correct content type has to follow that type. This would mean that the status-quo remains for those of us for obvious (UA), reasons returning XHTML as text/html, but gives the option as older browsers stop being supported to move to application/xhtml+xml?
In the interim spider / parse software should be able to detect from headers XHTML even if served as text/html (again the status-quo normally) and act accordingly.
Share:
| Cerbera wrote: |
| to create a new web (3.0?) which would only permit XML. He is objecting to throwing HTML in the bin and making it mandatory for every page to only use XML, and for every browser to only accept XML. I also object to that desire. |
I think that's ultimately the right aim; clearly it will take time and never actually happen 100%, and I do think the w3c is too quick to abandon the idea of transitional standards. But as a statement of intent, I'd agree.
Share:
That's never going to happen, BC. If W3C instructed browser makers to bin the text/html modes they've spent years perfecting, W3C will be ignored. If a W3C working group tells everyone that all their text/html web content and services have to be scrapped, that working group will be ignored. If W3C tell Google that they are no longer allowed to index text/html content, W3C will be ignored.
But we already know this since it's already happened!
Web browsers can already handle tag soup. Even modern mobile phones can do quite good error handling. All that's needed is the continued voluntary take-up of web standards by authors and browsers. Then we'll have even better interoperability in the text/html environment, with no need to scrap anybody's hard work.
Share: