Re: Custom Elements: 'data-' attributes

On Thu, 08 May 2014 19:42:04 +0200, Ian Hickson <ian@hixie.ch> wrote:

> On Thu, 8 May 2014, Bruce Lawson wrote:
>> On 7 May 2014 20:03, Ian Hickson <ian@hixie.ch> wrote:
>> >
>> > Requiring a dash is pretty ugly. I would allow any attribute, and
>> > we'll just have to be careful when introducing new global ones.
>>
>> I think the ship HMS Ugly has already sailed, given a dash is compulsory
>> for the names of custom elements. Also, requiring a dash in the names of
>> custom attributes would establish an easily-memorable convention for
>> authors, and safeguard new global attributes.
>
> I disagree.

I think the HMS ugly really has been launched - and successfully sailed  
for years. I agree with Bruce that dashes in attributes are easy for  
everyone to remember. The question is really how important that is.

> With element names, you really should be putting a uniquish
> prefix on your element names to avoid clashes with other custom vocabs.  
> So the dash is just the way we encourage that.

Right.

>    <google-button>
>    <yahoo-button>
>
> ...etc.
>
> But the attributes are _already_ scoped, since they're on the element.
>
>    <android-patterngrid width=3 height=3>
>
> ...vs
>
>    <android-patterngrid data-width=3 data-height=3>
>
> The "data-" bits don't add anything useful.

if they were andr- they might remind authors that this is a width  
specifically scoped to the element (and measured in unicorns, or somehow  
different from the "normal" width). For more obviously custom attributes  
like

<translation-tracker tt-src="http://example.org/yvfol">

I suspect this is actually helpful for authors in "getting it right".

But if we simply require everything to be data-* I agree that we're not  
likely to help anyone much.

So if we are going to do something, IMHO it should look more like "your  
attributes must have a dash in their name…"

> Anne's point about the DOM interface also being an issue is very  
> important also.

Yes.

> Unless we're also going to be forcing everyone to prefix their
> APIs, which would also be really ugly, the namespace wouldn't be
> protected anyway.

True…

This a price of ditching XML and namespaces (which was done because there  
were benefits too). Those things are seperable, and there is no law that  
we can never re-invent namespaces for an HTML world if it turns out that  
the functionality really was needed.

Hence my initial question - can we get a really important benefit for some  
(more) ugliness in the Web platform, do we need to find another solution,  
or is the problem so small we don't need to worry? I'm dubious about the  
last suggestion, but whether one or the other of the first two is more  
likely to be correct isn't immediately apparent to me.

cheers

chaals

-- 
Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
       chaals@yandex-team.ru         Find more at http://yandex.com

Received on Tuesday, 13 May 2014 11:18:16 UTC