[whatwg] Custom elements and attributes

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

Received on Friday, 3 November 2006 13:40:33 UTC