Re: Making all elements and attributes that contain hyphens valid

hey mike,

so is the use of data- in the G+ button public or private?

<!-- Place this tag where you want the +1 button to render. -->
<div class="g-plusone" data-annotation="inline" data-width="300"></div>

https://developers.google.com/+/web/+1button/

--

Regards

SteveF
HTML 5.1 <http://www.w3.org/html/wg/drafts/html/master/>


On 16 October 2013 07:28, Michael[tm] Smith <mike@w3.org> wrote:

> Silvia Pfeiffer <silviapfeiffer1@gmail.com>, 2013-10-16 16:52 +1100:
>
> > On 16 Oct 2013 15:29, "Michael[tm] Smith" <mike@w3.org> wrote:
> > > But if you want them to actually be useful for making video element
> > > work more easily with WebRTC, it seems likely you're planning for
> > > browsers to do something with them, and you'd want browsers to do that
> > > thing  interoperably and so you'd want it to be standardized somewhere.
> >
> > We're developing a library that makes life with webrtc simpler. I can't
> see
> > it being adopted into HTML any time soon, since what it does is: execute
> > JavaScript code.
>
> OK, I see.
>
> > > I think if people started piggybacking off data-* for non-private stuff
> > > like this just to not get error messages from the validator, I'd be
> > > tempted to have us just start making the validator emit warnings for
> > > data-* attributes that have multiple hyphens in them, or something --
> > > to discourage that kind of abuse of data-*.
> >
> > Private and non-private are not the only concepts in a world where
> > libraries are being reused between different applications.
>
> A library is by definition non-private. I don't see a gray area there.
> data-* isn't intended for use in libraries. I think there's nothing wrong
> with a library minting attribute names as long as there's good
> documentation about what the attributes are and how to use them.
>
> > In particular when you look at node modules, you can foresee this
> > happening more frequently in future.
>
> I understand. But my point is, that's not what data-* is for. If libraries
> are minting attributes that they intend for non-private use, they shouldn't
> be using data-* for that. And whatever might motivate them to use data-*,
> we should fix that so that they aren't inclined to do that.
>
> > > > Or should we do what angular did?
> > >
> > > It seems to me that what angular does makes a lot of sense for
> attribute
> > > names in a library that aren't meant to ever be supported natively in
> > > browsers.
> >
> > Right. That's what we're doing. Like ag-* we'll just have to live with
> the
> > attributes not parsing as valid then.
>
> If/when you publish documentation for the attributes, we could add support
> for them to the validator. Especially if you or somebody else with a stake
> in the work were to take the time to provide a patch. (Which by the way is
> how the its-* support got added to the validator: Jirka forked the
> validator code, did all the work of implementing the validator support for
> the its-* attributes, and sent pull requests with patches.)
>
> Anyway, in general, if there's a proper specification for something, we can
> add support for it to the validator. As a validator maintainer I personally
> couldn't care less if the spec for it were published at the W3C (as the
> spec for the its-* attribute was) or any other SDO, as long as whatever
> documentation there is does actually provide authors with the information
> they need to use the attributes as intended.
>
> And to be clear, I mean we could add it as an option in the validator, not
> necessarily as the default. And we could if we wanted to even add something
> in the default that while checking a document, if it finds ng-* attributes,
> causes a message to be emitted saying something like, "It looks like this
> document contains some AngularJS ng-* attributes. To check documents
> containing AngularJS ng-* attributes, consider enabling the relevant option
> in the validator." If somebody cared enough about having the validator do
> that to take the time to write up a patch, I'd personally be really happy
> to have it, and to be able to tell Web authors we have it.
>
>   --Mike
>
> --
> Michael[tm] Smith http://people.w3.org/mike
>
>