On 31 Oct 2006, at 11:46AM, Henri Sivonen wrote: > If you add custom *elements* and use the HTML parser, the system does not > ensure that the custom elements would not adversely interact with tag > inference > or error handling in browsers. [...] If you add custom elements, you just > have to > know what you are doing in order to keep the results useful for the purpose of > authoring for browsers.
My idea was to allow custom elements only in contexts where such problems do not occur. >>> non-XML characters [should not be allowed in HTML5] >For example, \0, form feed and U+FFFF Right, I did not even dream of allowing such characters in names. HTML 4.01 and XML 1.0 both disallow the surrogate characters U+D800âU+DFFF, as well as control characters < 32 (except \t, \n and \r). Additionally, HTML 4.01 disallow the range U+7FâU+9F, and XML 1.0 the characters U+FFFE and U+FFFF. I was therefore surprised to realise that the current HTML5 draft seems to allow any character except \0. Unless I have missed something, the character repertoire should probably be restricted somewhat, possibly to the common subset allowed in both HTML 4.01 and XML 1.0'. > Actually, I should have said that the minimum condition that I think is > necessary for a name of a custom attribute or element to be reasonable is that > the name matches the NCName production from Namespaces in XML 1.0 I agree with the intention that names should be restricted to (mostly) letters and digits, and this is probably the only usable definition we will get any time soon. > and only contains characters from the Basic Latin (ASCII) block. Is this because of case-folding issues? Unless there are other problems, an alternative would be to let non-7-bit characters be case-sensitive (with a strong warning against using names that only differ in case). >> I [...] find it unfortunate that custom attributes are not allowed in a >> conforming HTML5 document. > It does not necessarily follow that custom attributes have to be conforming. Well, no, not *necessarily*, but features that are useful universally implemented already and do not involve particular problems, should probably have a chance to make their way into HTML5. -- Ãistein E. Andersen
