[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
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
More information about the whatwg
mailing list