Re: Making all elements and attributes that contain hyphens valid

Silvia Pfeiffer <silviapfeiffer1@gmail.com>, 2013-10-16 19:03 +1100:

> On Wed, Oct 16, 2013 at 5:28 PM, Michael[tm] Smith <mike@w3.org> wrote:
> > Silvia Pfeiffer <silviapfeiffer1@gmail.com>, 2013-10-16 16:52 +1100:
> >
> >> 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.

So I was wrong about that. See my reply to Steve. The spec doesn't actually
say what I thought it said; it says that one of the uses of data-* is for
pretty much exactly what you've described.

So I think in terms of what they spec says, there is a gray area here.

> > 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.
> 
> OK, but library developers aren't generally SDOs, so while there may
> be documentation, there will generally not be an actual "standard
> specification" that could be used to point to for adding it to a list.

If that's the case, then I think the library developers are doing a
disservice to their users. I'd think they at least could provide something
like https://developers.google.com/+/web/+1button/#plusone-tag-attributes

> >> 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.
> 
> I think we haven't provided sufficient information for JS library
> developers to decide whether to use data-* or not.

Yeah, agreed.

> The "extensibility" section talks about private use for data-* and
> non-private use should be standardised. JS libraries fall between these -
> are neither private, nor standards.

Right. I can see that now. (Sorry, I guess I  made the mistake of arguing
on the basis if what I think the spec should say, rather than what it says.)

The only real benefit of data-* I've ever been able to see is the
convenience of the dataset property. But IMHO that doesn't seem worth quite
as much weighed against the side effect of (A) libraries adopting data-*
for non-private use, with data- prefixed names that end up becoming sort of
de facto standard attribute names with well-defined microsyntax/ datatypes
while (B) the spec says that there are no invalid values for data-*. That
situation is not helpful to Web authors.

> >> > > 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.)
> 
> Fair enough. We should probably do that when we see uptake of the library.

Yeah. But I think it will be more practical to do that if the libraries
just do what they did before there was data-* -- what AngularJS still does.

> > 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.
> 
> Right, as stated above: the need to have a specification at a SDO is
> what I think is asking for too much.

It's imaginable that there might be places where publishing a spec and
getting feedback on it can be a lighter-weight and less contentious task
than it is in some other places. Just speaking hypothetically.

> > 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.
> 
> That sounds sensible to me. And it also confirms Robin's suggestion to
> encourage library developers with a standard means of extending
> attribute names (with xxx-*) and then writing a patch for that xxx
> extension for the validator(s). I think it's worth an additional
> comment in the extensibility section.

Yeah, some more guidance in the spec on this topic would be useful.

  --Mike

-- 
Michael[tm] Smith http://people.w3.org/mike

Received on Wednesday, 16 October 2013 08:54:21 UTC