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: Tue, 13 May 2014 09:54:38 -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: <C7C85169-A357-4326-92D9-0D39C6DA7C8D@apple.com>
To: Anne van Kesteren <annevk@annevk.nl>

> On May 13, 2014, at 2:37 AM, Anne van Kesteren <annevk@annevk.nl> wrote:
>> On Mon, May 12, 2014 at 9:39 PM, Ryosuke Niwa <rniwa@apple.com> wrote:
>> But expandos are usually added to HTMLElement and other builtin elements, right?
> Depends, might be on instances too.

Sure, authors can do anything they please to do but a typical workflow is to define a property on element's prototype.

>> What we're talking about here is adding properties and methods on a custom element, which is a subclass of HTMLElement so I don't think it'll cause the same issue.
> If a site has if (ele.prop) you'd have that issue since that suddenly
> starts returning true for e.g. the <body> element or some such.
> Similar reason is why getElementById() is not available on elements.

Right. I think we need to discourage authors from using such an idiom on inprefixed author defined properties.

If authors are writing terrible code, there is so much we can do to mitigate that.

> Sole had the idea of providing hooks for attributes so a component can
> say it handles them rather than the user agent. That makes a lot of
> sense to me. That way you can grab any name, even existing ones.

Sounds like a sensible idea.

- R. Niwa
Received on Tuesday, 13 May 2014 16:55:07 UTC

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