[whatwg] Custom elements and attributes
Øistein E. Andersen
html5 at xn--istein-9xa.com
Fri Nov 3 13:40:33 PST 2006
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
More information about the whatwg