Re: Making all elements and attributes that contain hyphens valid

On Wed, Oct 16, 2013 at 7:54 PM, Michael[tm] Smith <mike@w3.org> wrote:
> 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.

Right. I didn't actually notice the section that you found - I only looked at
http://www.w3.org/html/wg/drafts/html/master/infrastructure.html#extensibility

But you are correct: I totally didn't see
http://www.w3.org/html/wg/drafts/html/master/dom.html#embedding-custom-non-visible-data-with-the-data-*-attributes


> 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

That's what I call "documentation", but not a standard. :-)


>> >> 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.)

I also didn't see it. I guess it has the answer for me.

> 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.

But it's ok - a parser just has to accept that the data-* attributes
are valid, it doesn't have to ascertain that the value is valid.


>> >> > > 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.

Indeed, we were quite confused about the spec's wording on this matter.

So, in your opinion, should we change
http://www.w3.org/html/wg/drafts/html/master/dom.html#embedding-custom-non-visible-data-with-the-data-*-attributes
to only apply to private attributes,

and add to
http://www.w3.org/html/wg/drafts/html/master/infrastructure.html#extensibility
the suggestion to use a custom prefix xxx-* for libraries?

Cheers,
Silvia.

Received on Wednesday, 16 October 2013 11:08:10 UTC