Re: Custom Elements: 'data-' attributes

> 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