Re: Making all elements and attributes that contain hyphens valid

Smylers <Smylers@stripey.com>, 2013-10-16 14:10 +0100:

> Michael[tm] Smith writes:
> > If you look at it from the perspective of authors using the attributes
> > from your library, I think the question should be, why would authors
> > want to use data-xxx-foo rather than xxx-foo.
> 
> It gives them the assurance that those attributes won't clash with
> future additions to HTML, nor with any other applicable standard.

I think in practice the library authors don't need to use the data- prefix
to provide that kind of assurance, and authors using the libraries don't
place much value on that assurance. Consider the case of Angular's ng-
prefixed attributes. I've not seen suggestions that things would be better
for authors if Angular were using a data-ng- prefix instead.

> They can safely use them, knowing that no user agent is going to
> interpret the attribute at all (so there's no risk of it interpreting it
> in an unintended way).

I think in practice authors can also safely use, e.g., Angular's ng-
attributes while knowing that no user agent is going to interpret the
attribute at all.

> The data-* namespace is safe for the site (including any libraries it
> uses) to do whatever it wants with, in the way that arbitrary attributes
> can't be.

As far as I can see, the only way in which the data-* namespace is
guaranteed to be safe is in the sense that UAs are prohibited from
implementing any native support for particular data- prefixed attributes.

But I can't see that data-foo-* attributes are any more safe than foo-*
attributes in any other ways. For example, using a data-foo-* prefixed name
in your site content doesn't ensure that you'll never run into a name-
collision problem of some other library coming along later that you want to
use in your site too but that has data-foo-* names for different purposes.

> (Or, if all attributes with hyphens in were deemed safe for authors to
> use like this,

What is "like this"? If you mean, if all attributes with hyphens were
deemed safe from every having UAs implement any native support for them
(the way that data-* attributes are), then I don't think anybody so far has
proposed that.

> that would prevent any future applicable spec from
> defining any new attributes with hyphens in them: they may clash with
> attributes authors or libraries are already using. That'd either be a
> massive restriction on future applicable specs, preventing any of them
> from using their own foo-* prefix on attributes.)

I think in practice the way we'd avoid such naming collisions is by trying
to use names that aren't known to have any conflicts with names that are
already in use. And to help with that we could even provide some kind of
registry for prefixes. I think such a registry has already been suggested.

> > Along with that, by providing authors with data-xxx-foo attributes to
> > use instead of xxx-foo attributes, you're making things harder for
> > authors to catch some kinds of authoring mistakes they might make. The
> > only way they're like to be able to catch syntax/datatype errors with
> > data-xxx-foo is by testing the code by running and hoping that it will
> > fail in some obvious way if they have a syntax error in a data-xxx-foo
> > value.
> 
> I don't see how that follows. In order for a validator to assist authors
> using libraries, it needs to know specifically about each library and
> what values are valid for its attributes. For each library that a
> validator knows about, it could provide options for users to indicate
> that the site is using, say, the Kapow library, and that the prefix in
> use for that library's attributes is data-kapow-.
> 
> Then the validator can check the values, just as it could if the
> attributes were called kapow-*.

That becomes more difficult if by default the validator is essentially
ignoring data-* attributes altogether. Which is a reasonable thing for the
validator to do, given that the spec says, "These attributes are not
intended for use by software that is independent of the site that uses the
attributes."

So to do what you describe, we'd need to tell the validator, "Ignore all
data-* attributes except ones that start with data-kapow-, data-ng-, etc."

That's doable but requires more complexity than just providing support for
checking of kapow- and ng- attribute values.

And regardless I think having validator support for checking values of
particular data-* attribute values goes against the semantics and authoring
expectations for data-* attributes in the same way that providing support
for checking values of the class attribute would.

> > Because by using data-xxx-foo you're basically buying into a contract
> > that says the attributes and their values should be ignored by any
> > applications except the library that they're designed to be run with.
> 
> If an author is running a validator on her own site, and has configured
> that validator to know that particular data-* attributes should obey
> particular syntax, I think it could be claimed that that run of the
> validator is effectively part of the author's site: the meaning of the
> attributes is only known because the author has baked this into the
> validator in an out-of-band way; the validator wouldn't be deriving any
> meaning from them based purely on their names.

Sure, in that hypothetical case.

> Or, if you think that that interpretation is too much of a stretch (you
> wouldn't be comfortable that such a validator feature would be compliant
> with HTML),

I wouldn't be uncomfortable with it at all. I'd in fact love to be able to
provide users of the W3C validator with some easy-for-authors way to teach
the validator about custom attributes in their documents, and to allow them
to check the syntax of those without me needing to provide built-in
knowledge of them within the validator itself.

> then we could change HTML to make an explicit affordance for
> the case of a validators looking at particular data-* elements when
> instructed to do so by authors.

I think it'd make as much sense to do that for data-* attributes as they
are defined now as it would to add some specific affordance in the spec for
looking at particular class values when instructed to do so by authors.

  --Mike

-- 
Michael[tm] Smith http://people.w3.org/mike

Received on Wednesday, 16 October 2013 15:13:29 UTC