W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2014

Re: Custom Elements: 'data-' attributes

From: Ryosuke Niwa <rniwa@apple.com>
Date: Fri, 09 May 2014 03:56:15 -0700
Cc: Brian Kardell <bkardell@gmail.com>, Glenn Maynard <glenn@zewt.org>, Ian Hickson <ian@hixie.ch>, Wilson Page <wilsonpage@me.com>, Dimitri Glazkov <dglazkov@google.com>, "public-webapps@w3c.org" <public-webapps@w3c.org>
Message-id: <B13D5DD1-30F0-4858-A45F-F8AEF87C8ABE@apple.com>
To: Anne van Kesteren <annevk@annevk.nl>

> On May 9, 2014, at 3:22 AM, Anne van Kesteren <annevk@annevk.nl> wrote:
> 
>> On Thu, May 8, 2014 at 6:49 PM, Brian Kardell <bkardell@gmail.com> wrote:
>> What do the parsing rules say about what an attr may begin with? Is it
>> plausible to just leading underscore or leading dash them as in CSS so that
>> all that's really necessary is for HTML to avoid using those natively (not
>> hard, cause, why would you) and then you provide an easy hatch for good
>> authors and get decent protection without getting too crazy?
> 
> _test="" or -test="" works fine. However, if we advice developers to
> mint attributes like that and APIs like ele._test() I'd imagine they'd
> laugh at us. Not exactly a great improvement over the status quo.

I don't think we can equate name collision in attribute names with that of method names.

The reason name collisions in attributes is bad is because attributes define directives for UAs to follow. This doesn't apply to element methods which define the API surface for authors.

Suppose we didn't have "contenteditable" today and someone had defined a custom element that used this attribute name for some other semantics C.  If we then introduced this attribute for what it stands today, semantics P, we'll be in a trouble because UAs would start treating custom elements' contests as if they were editable.

On the other hand, if the same element had exposed contentEditable property, then UA's native contentEditable property would simply be overridden since it would appear higher up in the prototype chain.  It's true that this custom element's contentEditable would have completely different semantics from that on other elements but that wouldn't break websites that use this custom element as long as authors are only accessing contentEditable property on instances of the custom element for semantics C.

- R. Niwa
Received on Friday, 9 May 2014 10:56:43 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:24 UTC