Re: Making all elements and attributes that contain hyphens valid

On Wed, Oct 16, 2013 at 1:02 PM, Sam Ruby <rubys@intertwingly.net> wrote:
> 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...

That makes sense for things that you'd want to get into the spec. But
what about yandex wanting to use attributes just for their own
applications only? yandex-* would come up as invalid. Having to do
data-yandex-* seems unwieldy.

Silvia.

Received on Wednesday, 16 October 2013 02:58:12 UTC