[whatwg] Custom elements and attributes

Øistein E. Andersen html5 at xn--istein-9xa.com
Mon Oct 30 15:03:16 PST 2006

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

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

More information about the whatwg mailing list