This blog can't be viewed on LiveJournal. Instead see http://www.apparently.me.uk/13890.html.

HTML 5 vs. Yadis

19th Apr 2008

One of the ways that the Yadis specification allows for the XRDS document location to be declared is via the X-XRDS-Location header embedded via a <meta http-equiv="..."> element in an HTML document. <meta http-equiv="...">

HTML 5 has constrained <meta http-equiv="..."> so that it only supports a selection of explicitly allowed headers. At the time of writing, these are "Content-Type", "default-style" and "refresh".

The result of this is that it is impossible to use Yadis in this way while having a conforming HTML 5 document. The current ethos for HTML 5 seems to be to remove any mechanism by which it can be extended in any way without going through the HTML working group and changing the core spec. While I can see the arguments for this in many cases, I don't really see the harm in allowing arbitrary extension HTTP headers (that is, those with an "X-" prefix) to be used in this way when there is a third-party specification that allows it.

It could be argued, however, that Yadis isn't using the http-equiv mechanism in the way it was intended to be used even in HTML 4. The HTML 4 spec for <meta http-equiv="..."> describes it as a mechanism used only on the server; the intention, I guess, was that HTTP servers would parse the HTML before it was served and create "real" HTTP headers matching the values given. I've never seen an HTTP server that actually does this, but it was apparently never intended to be processed by clients.

Fortunately, those who wish to use Yadis while still having a conforming HTML 5 document can use the proper HTTP header X-XRDS-Location. The same cannot be said for OpenID's extensions via <link rel="...">, which are apparently not allowed in HTML 5 either.

Comments

  • (comment with no subject)

    Actually, there's a wiki page where you can register rel values: http://wiki.whatwg.org/wiki/RelExtensions It seems that OpenID is covered already.

    I suppose we could have the same for pragma directives, though on the other hand <link rel> and <meta name> should be enough.
    By [info]id.annevankesteren.nl at 04:24 pm on 19th Apr 2008

    • (comment with no subject)

      I'm glad to see that there is a wiki page for rel as well. I saw the one for <meta name="..."> but must have missed the link to this one in the draft.

      I agree that the way Yadis handles this is not optimal. When originally proposed it was either a <meta name="..."> or a <link rel="..."> (I don't recall which) but it got switched when the X-XRDS-Location header was adopted. The HTML4 interpretation of <meta http-equiv="..."> doesn't seem to have caught on; it seems far more common for it to be used as an alternative way for user-agents to find certain HTTP header values.

      I see that HTML 5 is defining how to process the content of these rather than simply referencing the specification for the relevant HTTP header. I assume that there was some strange legacy behavior that made this necessary, but it's a shame that the HTML spec couldn't just leave this generic.

      By Martin Atkins at 07:09 pm on 19th Apr 2008

      • (comment with no subject)

        It's not generic in practice -- you can't just stuff HTTP headers in the bit and have it work. The processing for some of the headers -- Content-Type for instance -- is completely different based on whether it's in the HTTP headers or in the document.

        We probably will be adding a wiki page for http-equiv in due course, with the requirement being that for those values, the processing must be exactly as it would have been if the HTTP header was specified.
        By ianhickson at 10:55 pm on 19th Apr 2008

        • (comment with no subject)

          This seems like a reasonable compromise. I'll look out for the new wiki page. Thanks.

          By Martin Atkins at 10:12 am on 20th Apr 2008

  • Or just hate on HTML5

    HTML5 is not exactly something we have to be concerned about at this point - we're *almost* to the point where HTML4 is properly supported, then maybe we can work on XHTML1/1.1 - by the time we need to care about HTML5 hopefully it will have either died or just not suck so much :)
    By [info]singpolyma [singpolyma.net] at 08:04 pm on 23rd Apr 2008

    • Re: Or just hate on HTML5

      I'm not an unconditional proponent of HTML5 myself, but I do believe that the lack of a complete implementation of HTML4 or XHTML1 was one of the driving concerns for HTML5.

      HTML5 seeks to document what browsers currently do alongside all of that weird new stuff they're adding. This means that many browsers will be automatically more conformant with HTML5 than they are with HTML4. Of course, they'll still have to implement all of these weird and wonderful new features, which I agree is likely to take quite some time.

      By Martin Atkins at 08:27 pm on 23rd Apr 2008