Re: Making all elements and attributes that contain hyphens valid

On 16 Oct 2013 15:29, "Michael[tm] Smith" <mike@w3.org> wrote:
>
> Silvia Pfeiffer <silviapfeiffer1@gmail.com>, 2013-10-16 10:07 +1100:
>
> > We're currently building a library that introduces new attributes to
> > make video elements work more easily with WebRTC. What should we call
> > our attributes?
>
> Based on your description I'd suggest you probably should just give them
> good, specific, unprefixed names. But from just that description, it's
hard
> to tell. I think it'd depend on whether you actually need for browsers to
> do something with them, and whether you'd also need to add the attributes
> to the MediaElement interface or whatever.
>
> > It doesn't seem like something that would be standardised any time soon.
>
> 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.

> > It would be good to not just use data-* attributes because there could
be
> > collisions.
>
> And also because data-* is not intended for the case you're describing.
>
> > Should we sub-namespace it? data-rtc-* just to get not invalid attribute
> > messages?
>
> 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. In particular
when you look at node modules, you can foresee this happening more
frequently in future.

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

> It makes a lot less sense for any attribute names that you want
> to ever have browsers implement support for directly.

Yes, sure.

Silvia.

>   --Mike
>
> > This is without even looking at Web Components.
> >
> > Silvia.
> > [with web app dev hat on]
>
> --
> Michael[tm] Smith http://people.w3.org/mike