[whatwg] Proposal: Change HTML spec to allow any arbitrary value for the <meta> "name" attribute

Smylers Smylers at stripey.com
Tue Jun 4 05:45:47 PDT 2013


Robin Berjon writes:

> On 04/06/2013 11:08 , Smylers wrote:
> 
> > Michael[tm] Smith writes:
> 
> > > we receive a lot of comments and bug reports from confused/
> > > frustrated users who are trying to use values for meta at name that
> > > are not registered.
> > 
> > Could you give some examples of the kinds of <meta> names people are
> > using?
> 
> I've seen quite a few. One recent example is bug-assist.js — a
> script that makes it easy for readers of a document to file bugs
> about it — that looks for all metadata names that start with "bug."
> and uses the remainder of the name as parameters to a Bugzilla bug
> entry.

Thanks. That's really helpful for understanding the issue.

> The point is often that the person seeing the validity error is not
> the same person who defined the metadata name.

That seems to be an instance of the general scenario where a page
includes some components provided by third parties (including where the
main content is inserted into an outer template provided by a third
party), and where a diligent local author wishes to check for errors in
her content but not be nagged over problems in parts of the page out of
her control.

If the third parties care about conformance (or at least care about not
losing customers who care about conformance), then they will be amenable
to fixing bugs, such as the one Simon reported for bug-assist. And
indeed in this case the validator error does something useful.

If the third parties _don't_ care about conformance then there could be
any sorts of errors in code they provide, not just those relating to
<meta name=...> -- in which case it doesn't sound like it's going to be
possible to quell all the error messages that third parties could make
while still notifying authors about problems with their part.

Maybe instead a validator could let an author select which portion of a
page she has jurisdiction over?

Or perhaps it could allow uploading both a 'known bad' empty template
and a complete page, and only complain about errors in the second that
aren't also in the first?

(That would also help in a similar situation when editing an old,
non-conforming site, and wishing to check that you haven't introduced
any new errors, but aren't in a position right now to fix all the
existing ones. You could upload the current error-strewn page and your
proposed change, and only be told about errors you have introduced.)

> It [registering <meta> names] doesn't seem to buy anyone much, either.

That seems a more interesting assertion.

Is any harm actually being caused by rogue <meta> names? If somebody
changes bug-assist to use data-* attributes instead, does that make the
world a better place -- or at least enough of a better place to be worth
doing?

The benefits would seem to be in avoiding naming clashes:

* To bug-assist's developers (and users) it avoids that somebody else in
  the future mints clashing <meta> names which have a different meaning,
  and starts erroneously interpreting data intended for bug-assist .

* To other minters of <meta> names it reduces either complaints about
  clashing or time spent checking for clashes (without a central list).

  Having a canonical list of allowed names and a validator that
  complains about names not on the list means that in the event of a
  clash, there's a place where a party using an unregistered name can be
  alerted to the possibility in advance. Whereas with any value allowed
  they don't get that.

Note, I'm not saying those benefits do constitute sufficient reason to
keep the check -- just that we should consider them, so that if we then
abandon the check we have decided that they aren't worth bothering with.

Cheers

Smylers
-- 
Stop drug companies hiding negative research results.
Sign the AllTrials petition to get all clinical research results published.
Read more: http://www.alltrials.net/blog/the-alltrials-campaign/



More information about the whatwg mailing list