What Dean says so well here are also the reasons I prefer XML defined markup, and I don't think it negates the arguments that others have been expressing here for HTML. I think each on of them have valid points. But it seems to me that there are more reasons to use an XML based vocabulary than have previously been put forward.
I also agree with him about writing parsers and their performances based on stricter or looser rule sets. I also try to see XML vocabularies as having a richer and more accurate rule set to express the content they encapsulate. I dream of a true semantic web were I can find content from searches that are based on arguments and phrases that are derived from clean document tree analysis of content. Even if we have those documents out there, current search methods and technology are far too primitive to understand that. Not that the search engine engineers are dumb, it's just that for all the content out there, there are only small portions of it that can be stored and analysed semantically, so there is not much point in doing that regarding ROI. And I don't agree with a lot of the way the W3C are handling the semantic web. ----- Geoff Deering Dean Jackson wrote: > Friday, 8 October 2004 2:23 PM > On 7 Oct 2004, at 02:09, Vlad Alexander (XStandard) wrote: > > > Hi Kim, > > > > Ian Hickson is _not_ saying XHTML is harmful, he is saying that > > serving up XHTML with the wrong MIME type is bad. > > That's right. It's probably not the best title for the > document, but my feeling is that people using the "... considered > harmful" approach are typically looking more for attention than > for examination. > > Nevertheless, it's still an interesting read. > > > Today, the real benefits of XHTML are on the production side. Say your > > CMS has 1000 documents and you need to change the "class" name of a > > <div> tag in all 1000 documents. If your content is in XHTML, you can > > use XML related technologies like DOM or XSLT to process all 1000 > > documents quickly and accurately because XHTML can be processed by XML > > parsers. > > I agree. > > Using XHTML over HTML brings some benefits that are hard to measure. > The way I think of it is that XHTML allows more people to use your > content in ways that you didn't originally expect. For example, at > W3C we extract a lot of semantic info from our XHTML pages: building > calendars, issue lists, relationships between pages, etc. This could > all be done using HTML, but XHTML makes it easier (much wider range > of tools in the XML world). The same goes for modifying pages. I have > a huge range of tools available to do a site wide change with XHTML, > and these tools are interoperable because they conform to the XML > specification. If my Web guy gets hit by a truck, then I can > call up another developer and assume that her XML skills will be > enough to do the job (even though she may not be familiar with the > tools). > > Then there is the whole Web Applications trend. Again, HTML and > XHTML are pretty much the same in functionality here, but if I'm > using an application on the Web then I want to make sure it is > well-formed and well-structured. I don't want a typo by a web > developer (such as leaving off an end tag) to cause my credit > card to be debited twice. That's an extreme example, but in the > general case, would you really run an application on your desktop > that you were not sure was compiled correctly (or had millions > of compiler warnings)? Allowing sloppy markup in applications > is a security risk IMHO. > > On the design front, if you are thumping your head against a > wall trying to wonder why the page is off by three pixels, wouldn't > you like to rule out as much as possible in order to reduce the > number of places you look for the bug? In most cases, this is > easier with XHTML - you can check the document and then focus > on the CSS. > > While the existing browsers are parsing and rendering HTML faster > than XHTML, then you can serve XHTML 1.0 as HTML. I'm not sure > exactly why HTML parsing/rendering is faster than XHTML, since in > general it is much easier to right a high-performance parser for > a strict language than a less strict one (and HTML also carries > years and years of quirks to handle). Maybe it is just that the > HTML code has been around for so long that it is highly optimized. > Let's hope the desktop browsers will move into 2001 soon ;) > > To ask the question the other way around, what are the real > benefits of using HTML over XHTML? I'm interested to hear the > reasons (and I'm sure they are valid). > > Dean > ****************************************************** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help ******************************************************
