Re: Making all elements and attributes that contain hyphens valid

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

Received on Wednesday, 16 October 2013 06:28:32 UTC