Re: Making all elements and attributes that contain hyphens valid

[See the reply below the original message]

19.09.2013, 19:19, "Robin Berjon" <robin@w3.org>:
> Hi all,
>
> I opened a bug about this[0] but I'd like it to see broader discussion.
>
> As per Web Components today[1], elements that contain a hyphen in their
> names are clearly laid open for third-party extensibility (a few
> exceptions are listed, grandfathered from MathML and SVG).
>
> I'd be more comfortable if HTML were the one to make that promise, and
> also if it made it more explicitly. Furthermore, I think that the
> logical conclusion from that is that where validators are concerned,
> elements containing hyphens ought to always just be considered valid.
>
> Additionally, I believe we should make the same commitment for
> attributes. Currently we have data-* attributes, but those are not meant
> for software that's distinct from the site or application that uses them
> (i.e. they're not usable for general purpose extensions, and that's a
> good thing).
>
> Making hyphen attributes valid in all cases (minus existing ones such as
> aria-* and those from SVG/MathML) would allow third parties to produce
> their own using weak (but sufficient) namespacing (e.g. epub-*). It
> won't hurt HTML since we're already committed to not use hyphens in
> names anyway.
>
> Naturally, it would be useful to advise such third parties that they
> would be better off getting any generally useful such attribute
> standardised. But it provides a valuable escape hatch for when there is
> no agreement to introduce such features into HTML. Right now the
> alternatives are:
>
> ššššš1) Use namespaces; bad idea, forces XHTML.
> ššššš2) Use data-$prefix-*; bad idea, not meant for that.
>
> The impact on user agents is zero, only validators are impacted.
>
> Thoughts?
>
> [0] https://www.w3.org/Bugs/Public/show_bug.cgi?id=23254
> [1]
> https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/custom/index.html#dfn-custom-element-type
>
> --
> Robin Berjon - http://berjon.com/ - @robinberjon

As a web developer, I'm not too comfortable with attributes that don't have dashes between words since omitting such separator makes attribute name quite difficult to read and somewhat ambiguous. For example:

`formnovalidate` can be read as something like `for m no val id at e`, i.e. "FOR some M, there is NO some VALue, and some ID should be looked at some E".

With dashes, it would be easy to read and unambiguous:

    `form-novalidate`

So maybe it makes sense to rename all such attributes (while saving their current meaning) to dashed ones in future versions of HTML, and, given such possibility, it may be not a too good idea to just allow all custom prefixed attributes unconditionally.

As for custom elements and attributes, if it's OK to have nonlatin characters (dashes in particular) in element tag-names, then it may make sense to reserve some general _short_ prefix for such purposes.

For example `n-` (abbreviation from "nonstandard"):

    <n-example></n-example>

or `_` (something that standard element tag-names will most likely never begin from):

    <_example></_example>

>From `n-` and `_`, I personally would prefer the `_` prefix since it's most clean, clearly nonstandard, perfectly neutral, and extremely short (no another prefix can be shorter).

FWIW, there is an elaborated proposal on allowing UNprefixed custom HTML elements in a completely _future-proof_ way -- without any compatibility issues:

https://www.w3.org/Bugs/Public/show_bug.cgi?id=14011

As for custom attributes, in practice, `data-` prefixed attributes look quite fine for storing any nonstandard data (regardless of whether it was _intended_ for that) for exception of that the `data-` prefix is just somewhat too long. So we could reserve a short prefix like `n-` or `_` for nonstandard attributes as well. For example:

    <p _epub-foo="bar" _epub-bar="ipsum"></p>

would then be valid and could be freely used like `data-` attributes are used currently.

Thanks.

Received on Thursday, 19 September 2013 17:41:16 UTC