This content was published by Andrew Tomazos and written by several hundred members of the former Internet Knowledge Base project.
XHTML - can browsers and authors be strict enough?
Dave Everitt: Well-formed HTML is a breeze to change to XHTML (and BBEdit, the Mac programmers text editor automates the process). 'Well-formed' is the key - if you start with valid HTML, the basic differences are:
1. every tag must have an ending tag (self-closing tags like and become and );
2. all tags are lower-case (none of that 'shouting' HTML of yore becomes - shhh - );
3. tag attribute values must be quoted (
becomes
, and )
4. the DTD changes, and is prefixed by an (optional) XML prologue (which conflicts with the shorthand PHP tag
However, the thorny practical issue is the way various browsers render XHTML. Some develpers feel that XHTML 1.0 currently invokes more rendering headaches in partly-compliant browsers, and have dropped back to using well-formed HTML 4.01. For the average site, Why (they argue) use XHTML at all?
It could be argued that the real advance XHTML has encouraged is an awareness of well-formed (X)HTML. However, due to the problem of having to render all the badly-formed HTML that now exists on the web (probably for the the lifetime of the average developer), browsers are unlikely to complain about rubbish code for many years to come (if ever).
That's why standards compliance is a much more important issue than the HTML/XHTML change - so long as bad code is allowed (as generated by ill-used visual editors, for instance), browsers will be obliged to at least have a go at rendering it.
The increasing awareness of standards also seems to have killed off the older issue of browser manufacturers going it alone (although the innovation this sometimes drove is still necessary). In 2005/6 it's unlikely that we'll see a browser manufacturer deliberately seeking to 'add' a proprietory tag to the standard without agreement (goodbye, 'blink').