W3C home > Mailing lists > Public > public-html@w3.org > October 2009

Re: data-* attributes [was: Re: ISSUE-41/ACTION-97 decentralized-extensibility]

From: Shelley Powers <shelley.just@gmail.com>
Date: Mon, 19 Oct 2009 15:56:05 -0500
Message-ID: <643cc0270910191356q45065223y16612cecc614d81e@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: James Graham <jgraham@opera.com>, Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>, Anne van Kesteren <annevk@opera.com>, Adrian Bateman <adrianba@microsoft.com>, Jonas Sicking <jonas@sicking.cc>, Tony Ross <tross@microsoft.com>, "public-html@w3.org" <public-html@w3.org>
On Mon, Oct 19, 2009 at 3:37 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> On Mon, Oct 19, 2009 at 3:20 PM, Shelley Powers <shelley.just@gmail.com> wrote:
>> Of course I won't withdraw my opinion.
> Then do you at least admit that it's currently merely an opinion,
> unsupported by any data?

I suppose we can toss data at each other, or use cases, or pull out
sentences from the HTML5 spec, but I don't see the point.

>> I don't believe that jQuery's use of the data-* attributes will
>> provide a solution for data that needs to be aggregated outside of the
>> page. It can't because that's a violation of the HTML5 specification
>> rules for data-*. However...
> Hm?  I'm not quite sure how we arrived here.  I don't think anybody
> was talking about this, were they?  I used jQuery as an example of how
> self-policed namespacing can work.  Nobody ever suggested anything
> about using data-* for data that needs to be aggregated outside of the
> page (as you say, that's against the HTML5 spec).  So this paragraph
> seems like it came out of left field.

But, to me, that's a requirement for decentralized extensibility. But
it's true, if we don't see data-* as being a viable option for
decentralized extensibility, then we don't need to be concerned.

>> I'm sorry if you took offense at my suggestion for you to write up a
>> proposal for data-* for decentralized extensibility. I just felt that
>> we could be going around in circles indefinitely on this topic,
>> exchanging opinions, disagreeing with each other, without a concrete
>> proposal.
> Oh, no offense taken, don't worry.  I just have no idea why you
> suggested it in the first place, as nobody ever suggested data-* would
> be used for anything of the sort.  This thread was solely about
> addressing a confusion concerning when it was appropriate to use
> data-* attributes.

Reading back, the first mention of "decentralized
> extensibility" was by you, in your first post on this thread.

Actually, I believe that it was Anne who introduced data-* into the
discussion about decentralized extensibility.

That was so long ago, though. So I'll take your word for it that I
introduced data-* and distributed extensibility into the discussion.

So, since it's not relevant to a discussion about decentralized
extensibility, we can just let this offshoot thread go.

>> A concrete proposal would then give us focal points on which to have
>> further discussion. Like the beginning proposal that Tony provided.
> But there's no need for such a proposal, since nobody had ever
> suggested that data-* would be appropriate for such a thing.  You were
> the first to mention "decentralized extensibility" in the context of
> this discussion, and you did so solely to state that data-* was not
> appropriate for implementing such.  I don't disagree, as long as we're
> clear that we're talking about implementing "decentralized
> extensibility" in the general case, where you may have, for example,
> crawlers reading pages and extracting information.


> In the specific case of allowing js widgets in a page to hold their
> own custom state for their own purposes, data-* is of course
> appropriate - that's what it was designed for.

Good point. Yes, you're right. Now that I look back at Anne's
statement, it was in regards to the widgets. I just tend to be focused
on the topic header, which is distributed extensibility. And that
influences how I read everything that follows.

> ~TJ

Received on Monday, 19 October 2009 20:56:34 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:45:01 UTC