Re: Making all elements and attributes that contain hyphens valid

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


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


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


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


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

Cheers,
Silvia.

Received on Wednesday, 16 October 2013 08:04:06 UTC