- From: Řistein E. Andersen <html5@xn--istein-9xa.com>
- Date: Tue, 31 Oct 2006 00:03:16 +0100
On 23 Oct 2006, at 12:43PM, Henri Sivonen wrote: > Using custom schemas with the HTML parser is for experts only > and produces very wrong results unless the schema is suitable. Indeed so, but then any tool can potentially be misused. Still, I do realise that this is not a priority, of course. > [Many clarifying details concerning the implementation > of the conformance checker.] Thanks a lot for these explanations. >> authors seem to have the possibility to use >> custom element and attribute names of their choice. > Could you please cite the part of the spec that says so? It does not say so /explicitly/, of course. I have certainly misread between the lines. > personally I am not at all sympathetic to extending HTML5 with names that > contain non-ASCII (due to case folding issues), It might be interesting to see how current browsers handle element names containing such characters: - Firefox does case folding for ASCII characters only: r??le = R??le != R??LE - Opera is completely case-insensitive: r??le = R??le = R??LE - IE7 does IDN-like case-folding: x:r??le = x:R??le = x:R??LE; moreover, x:?????????? = x:?????????? (sigma = word-final sigma) The current draft seems to describe Firefox's behaviour on this point. I would imagine that IDN-like case folding could easily be implemented in browsers that support IDN anyway, but this is arguably not very useful (at least not in the foreseeable future), and I do not particularly want to see this in the specification. None of these browser allow a tag name to /start/ with a non-ASCII letter, in line with the current draft. > non-XML characters (due to XML serializability issues) Which are those characters? Do you mean <, >, ", ' and &? > or the colon (due to Namespaces in XML compatibility issues). Sure; this is a very real problem, and backwards compatibility with IE may not be sufficient to endorse a quasi-namespace syntax. > Any attribute or element not specifically allowed in the spec is non-conforming. > Therefore, all "custom attributes" and "custom elements" are non-conforming. Custom attributes are (I believe, though I do not have any statistics to support this) quite common in the wild and can certainly be useful in combination with scripting. Furthermore, current browsers handle custom attributes effortlessly. I therefore find it unfortunate that custom attributes are not allowed in a conforming HTML5 document. Still, allowing /any/ attribute name would of course make it impossible to add new attributes later on (HTML6?); that is why I propose explicitly to reserve attribute names starting with "x-" (inspired by codes for custom languages, but any prefix would be fine) for use by authors and to make documents containing custom attributes of this form fully conforming. Ideally, I would like the same principle to apply for element names; such elements should probably be parsed as phrasing elements and be allowed to contain strictly inline-level content only to be conforming. Custom elements are potentially much more controversial (and less useful) than custom attributes; please do not automatically reject both proposals as a unit. -- ??istein E. Andersen
Received on Monday, 30 October 2006 15:03:16 UTC