XHTML 1.0 Compatibility Guidelines

The XHTML 1.0 standard has a non-normative appendix of Compatibility Guidelines – ways to code your XHTML to make it render reasonably well in HTML user agents. Of course, being the browser-neutral standards body that they are, the document doesn’t say exactly which browsers require which compatibility workarounds.

It would be rather cool if someone were to knock up a test page which used each of the possibly-problematic constructs (e.g. <br/> without the space, checked=”checked”, line breaks in attributes) and then made a matrix from the results people sent in when they pointed different browsers at it. This would give web developers some idea of which of the requirements were only for the benefit of long-dead browsers like, er, Netscape 4.

Any volunteers? :-)

12 thoughts on “XHTML 1.0 Compatibility Guidelines

  1. From my experience, no browser newer than Netscape 4 has problems with . As to checked=”checked” — the point here is that using an attribute without value wouldn’t be valid XHTML, so you really have to do this. Don’t know about line breaks in attributes, never used them (but I seem to remember that MSIE works fine with them). C.1 is really relevant — MSIE 6.0 switches to quirks mode if he meets an XML declaraction before DOCTYPE. The parts about not using

    or

    are pretty natural. C.4 is pretty tricky if you really need inline scripts. C.8 is something that you already need in order to support older Gecko versions (on frames). As to C.16, MSIE doesn’t know ', so this shouldn’t be used. The other points are more about producing valid XHTML than about backwards compatibility.

  2. Argh, your blog eats HTML tags :-(
    Same thing again, hopefully with tags now:

    From my experience, no browser newer than Netscape 4 has problems with <br/>. As to checked=”checked” — the point here is that using an attribute without value wouldn’t be valid XHTML, so you really have to do this. Don’t know about line breaks in attributes, never used them (but I seem to remember that MSIE works fine with them). C.1 is really relevant — MSIE 6.0 switches to quirks mode if he meets an XML declaraction before DOCTYPE. The parts about not using <br></br> or <p /> are pretty natural. C.4 is pretty tricky if you really need inline scripts. C.8 is something that you already need in order to support older Gecko versions (on frames). As to C.16, MSIE doesn’t know &apos;, so this shouldn’t be used. The other points are more about producing valid XHTML than about backwards compatibility.

  3. Argh, your blog eats HTML tags :-(

    Well, it does say so clearly just below the comment entry box…

    Could you expand upon your comments on C8?

  4. Argh, your blog eats HTML tags :-(

    Well, it does say so clearly just below the comment entry box…

    Not really; it says it “accepts some HTML”, not “accepts some HTML and destroys the rest”. It really ought to auto-escape anything it’s programmed not to accept. But I think that might be more Moveable Type’s fault than Gerv’s. But since I don’t use blogging software I can’t say for sure.

  5. Jason: it clearly says “You will need to escape as >.”.

    But you are right, I can’t make Moveable Type more magic.

  6. This blog *isn’t* xhtml, look at the headers. It only follows the XHTML syntax.

  7. Regarding C.8: In MSIE and older Gecko versions the window.frames collection was accepting frame names, in recent Gecko versions it requires IDs in XHTML mode. There was some other similar collection mentioned in the bug but I don’t remember. Btw using getElementById().contentWindow as a workaround usually can’t be used for reasons of compatibility with MSIE 5.0.

  8. Yes, this blog is very much not XHTML. It won’t work in many ways with proper XHTML headers. One reason is that the blog comments don’t need to meet XHTML requirements. The other that I can see at once is wrong escaping of inline scripts – they are put into comments which are really interpreted as comments (and thus ignored) in XHTML mode. And I’m sure there are more things wrong, Hixie’s Sending XHTML as text/html Considered Harmful really has a point.

  9. Yes, this blog is very much not XHTML.

    Indeed not. I didn’t realise until I looked just now that it has an XHTML doctype. :-|

    Could I switch it to an HTML 4.01 Strict doctype without anything breaking, do you think?

  10. Gerv, I’ve noticed that most blogging systems seem to generate XHTML by default, because it’s, you know, the latest thing and all. I don’t think fixing the doctype in and of itself will fix things because I’m sure that MovableType uses XHTML-isms like <br/> and so on throughout its templates; you’d then presumably have a supposedly HTML 4.0.1 Strict document that might not validate. This is true for MT plugins as well, for example the Markdown text formatting plugin (highly recommended BTW) assumes it will be generating XHTML.

    I fixed this in my own blog by using different blogging software (Blosxom) and then hand-tuning it myself so that everything would validate as HTML 4.01 Strict. (Of course, I have no comments system because Blosxom doesn’t come with one out of the box, and I haven’t hacked that in yet. But who needs comments, right? :-)