Re: Making all elements and attributes that contain hyphens valid

On 10/15/2013 07:39 PM, Charles McCathie Nevile wrote:
> On Wed, 16 Oct 2013 01:07:48 +0200, Silvia Pfeiffer
> <silviapfeiffer1@gmail.com> wrote:
>
>> On Thu, Oct 3, 2013 at 9:21 PM, Sam Ruby <rubys@intertwingly.net> wrote:
>>> On 10/03/2013 03:05 AM, Michael[tm] Smith wrote:
>>>>
>>>>
>>>> We don't want to make it harder for authors to know when they have
>>>> documents that contain names which aren't part of any standard, and we
>>>> don't want to make it harder for authors to catch misspelled attribute
>>>> names, and we don't want authors to end up being even further
>>>> limited in the choice of tools they can use -- limited to only using
>>>> tools
>>>> that are complex enough to understand all the magic we're introducing.
>>>
>>> [chair hat off]
>>>
>>> As implementer of a validator for another set of markup languages (Atom,
>>> RSSes), my thoughts match Mike's though I end up with a slightly
>>> different conclusion.
>>>
>>> WebComponents defines a mechanism by which new elements may be
>>> minted. So any name containing a hyphen may potentially be valid.  A
>>> page
>>> should only be validate without messages if such a name was actually
>>> minted, and can be verified as being used correctly.
>>>
>>> Note that I said "validate without message", not "considered valid".
>>
>> I think I'm with Sam here.
>
> I think I already said so.
>
>> 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? It doesn't seem like something that would be
>> standardised any time soon. It would be good to not just use data-*
>> attributes because there could be collisions. Should we sub-namespace
>> it? data-rtc-* just to get not invalid attribute messages? Or should
>> we do what angular did?
>
> We're looking at adding an attribute to link (to make Opensearch work a
> bit more flexibly). data-* seems wrong since it's required to be
> "private", although maybe that should change somehow. Namespaces got nixed.
>
> We expect to get a reasonable amount of usage, so we are quite open to
> writing an HTML extension spec, but what should we do if we are going to
> work with a new attribute and it doesn't get accepted. In particular, I
> am not that keen on using a vendor prefix like yandex-foo ...
>
> Any thoughts?

[chair hat off]

I agree, avoid 'data-'.  And 'aria-' while you are at it.  As well as 
'yandex-'.

XML style namespaces have a number of problems, but collisions aren't 
one of them.

As long as we have a small number of well known prefixes, perhaps 
collisions won't be a problem.  Perhaps a wiki would be sufficient.

Meanwhile, I would suggest following the lead of aria, and writing 
specs, getting implementations, and fostering usage.

Note the the existing validator checks for aria.  Not indiscriminately, 
but very deliberately.  If your spec gets anything resembling traction, 
I would expect that the validator will do the same for you.  Of course, 
you could speed up the process by providing a patch...

> cheers
>
> Chaals

- Sam Ruby

Received on Wednesday, 16 October 2013 02:03:28 UTC