Re: [whatwg] Proposal: Change HTML spec to allow any arbitrary value for the meta name attribute
On Tue, 4 Jun 2013, Michael[tm] Smith wrote: The context of the proposal is the following language in the HTML spec: Conformance checkers must use the information given on the WHATWG Wiki MetaExtensions page to establish if a value is allowed or not: values defined in this specification or marked as proposed or ratified must be accepted, whereas values marked as discontinued or not listed in either this specification or on the aforementioned page must be rejected as invalid. http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#other-metadata-names I propose we remove that language from the spec [...] For the past few years, we've been running an experiment here, getting people to register values on the wiki: http://wiki.whatwg.org/wiki/MetaExtensions We also have the rel extensions registry on the microformats wiki. Before we go further, we should probably discuss the problem that we're trying to solve with these registries, instead of just allowing any value to be used. These are the same reasons as for most things we make non- conforming at the authoring level: - helping authors catch cases where their intent is unclear - helping authors catch typos - helping authors avoid known interoperability issues - helping authors avoid wasting time (See also: http://whatwg.org/html#conformance-requirements-for-authors ) There's also the goal of just documenting what's out there, to help people who want to invent new values to avoid reinventing the wheel, or at least, to avoid reinventing it poorly. I think these goals are reasonable, and worth pursuing. We could just have wide-open extension points here, allowing any value, not bothering to define any. But I think this would be a net loss. From the aforementioned experiments with wiki registries, we've learnt several things, which I shall now discuss. Some of these are taken from mailing list discussions on this thread; thanks to the contributors thereto. Others are taken from IRC discussions earlier this week; thanks to Tantek and MikeSmith in particular for their comments: http://krijnhoetmer.nl/irc-logs/whatwg/20140122#l-552 http://krijnhoetmer.nl/irc-logs/whatwg/20140123#l-88 The first big lesson is that, maybe surprisingly, there's a lot of demand for these features. The long tail of needs for these values is very long indeed. Well over a hundred meta name keywords have been registered, and that ignores all the ones that people haven't bothered to register. Simultaneously, people are unhappy when validators don't know about their meta names. The modern HTML validators point people to the Wiki; for example, validator.nu says: You can register metadata names on the WHATWG wiki yourself. People follow the link and attempt to register values all the time. The barrier to adding values has been low, but still not trivial: you have to e-mail a request for a wiki account, then when you get it a few days later, you have to add the item to the wiki page which means editing MediaWiki's table markup. We get a few requests for accounts each week. We also get a number of people each week filing unclear bug reports on the spec asking, I think, for certain values to be registered. One lesson from this is that we could make this much easier, e.g. by having validators offer to register the keyword directly. The wikis for meta name and link rel have been wildly more successful than IETF/IANA registries, at least in terms of how many keywords they document. This is, presumably, due to the lower barrier for entry. If a goal is to document values used on the Web, then lowering the barrier to entry even further might increase the volume of documentation. Another lesson, though, is that if we make certain values non-conforming, we'd better have a rather convincing message for the validators to give the authors. Such messages should probably include an explanation as to why a value is non-conforming and a description of how to achieve the desired effect instead. Right now, the message is just Bad value ... for attribute name on element meta: Keyword ... is not registered. This may be the best we can do for unknown values (though maybe we could do better for typos, pointing people to the keyword they probably meant to use?), but if we start marking values as non-conforming because of issues with the values, we need to be clearer. Right now, for link rel extensions we have the concept of synonyms. This probably isn't sufficient for validators, though, and we don't have it at all for meta. Another anectodal data point is that based on the conversations I've had with people trying to register accounts on the WHATWG wiki so they can register keywords, many authors have no idea what these keywords are really for, despite being very sure they want to have them and not wanting validators to complain about them. I don't know what we can do about that, though.
Re: [whatwg] Proposal: Change HTML spec to allow any arbitrary value for the meta name attribute
Regarding meta and data-, when designing the Wakanda Framework, we have been
using both, and I must say I'd love to remove most of the data- attributes in
favor of standard attributes (like aria- ones) or class names.
The potential problem letting people create any meta name without declaring
them is potential conflict
JS Framework are now using a global object as namespace to prevent collisions,
Dublin Core proposed to do the same for meta tags
When using the meta approach we used the WAF namespace based on what was
doing Dublin Core with DC and DCTERMS namespaces
http://dublincore.org/documents/dcq-html/
They introduced this very interesting schema link tag:
link rel=schema.{prefix} href=namespaceURI
ex:
link rel=schema.DC href=http://purl.org/dc/elements/1.1/; /
link rel=schema.DCTERMS href=http://purl.org/dc/terms/; /
Unfortunately, to be HTML5 compliant Dublin Core had to list its full semantic
in the wiki:
http://wiki.whatwg.org/wiki/MetaExtensions
You can see by yourself the result...
This page already start to be large with twitter, globrix, msapplication, og
(open graph) namespaces, so I'm a bit worried on how it will looks like in few
years if any company add its own set.
The link tag also impose rel attribute values to be either included in
HTML5 specification or in a Wiki:
-
http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#other-link-types
- http://microformats.org/wiki/existing-rel-values#HTML5_link_type_extensions
The schema.{prefix} rel value is unfortunately not approved yet:
http://microformats.org/wiki/existing-rel-values#unspecified
On 4 juin 2013, at 06:42, Michael[tm] Smith wrote:
Feel free to ignore this proposal is you don't care much about document-
conformance requirements and validator/conformance-checker stuff. On the
other hand if you care about it and have some feedback to add, please do
weigh in if you have any feedback to add.
I also filed a bug for this, so feel free to respond there instead if you
prefer -
https://www.w3.org/Bugs/Public/show_bug.cgi?id=22257
The context of the proposal is the following language in the HTML spec:
Conformance checkers must use the information given on the WHATWG Wiki
MetaExtensions page to establish if a value is allowed or not: values
defined in this specification or marked as proposed or ratified must
be accepted, whereas values marked as discontinued or not listed in
either this specification or on the aforementioned page must be rejected
as invalid.
http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#other-metadata-names
I propose we remove that language from the spec; specifically:
1. Change the spec to allow the meta name attribute to have any
arbitrary value that a Web author would like to use.
2. Remove any spec requirement on conformance checkers to check meta@name
values.
3. Mark the WHATWG Wiki MetaExtensions page as obsolete (or whatever), as
it will no longer be useful/needed if the spec is changed to allow
arbitrary meta@name values.
Speaking from my perspective as a contributor to development of a
conformance checker: In practice, we receive a lot of comments and bug
reports from confused/frustrated users who are trying to use values for
meta@name that are not registered. And as far as the strategy of trying to
use the spec and Wiki page as a means to educate them about trying to
taking the time to register meta@name values and only use registered values
and standard values (those listed in the spec), well, that strategy is not
working well. They just want the validator to shut up.
I don't think much real harm would be caused in practice if we dropped the
requirement to only use standard/registered values and instead went back to
allowing documents to contain arbitrary meta@name values.
And again speaking specifically from my perspective a contributor to
development of a conformance checker, I think in practice more user time is
wasted by the existence of the current spec prohibition on unregistered/
non-standard meta@name values than would be wasted by allowing arbitrary
values.
--Mike
--
Michael[tm] Smith http://people.w3.org/mike
Alexandre Morgaut
Wakanda Community Manager
4D SAS
60, rue d'Alsace
92110 Clichy
France
Standard : +33 1 40 87 92 00
Email :alexandre.morg...@4d.com
Web : www.4D.com
Re: [whatwg] Proposal: Change HTML spec to allow any arbitrary value for the meta name attribute
Michael[tm] Smith writes: Speaking from my perspective as a contributor to development of a conformance checker: In practice, we receive a lot of comments and bug reports from confused/frustrated users who are trying to use values for meta@name that are not registered. Hi Mike. Thanks for sharing your wisdom on this. Could you give some examples of the kinds of meta names people are using? And do you have an idea which user-agents are acting on those names? I'm interested in whether the meta tags people are using are meaningless cruft or have useful effects in niche fields. And as far as the strategy of trying to use the spec and Wiki page as a means to educate them about trying to taking the time to register meta@name values and only use registered values and standard values (those listed in the spec), well, that strategy is not working well. They just want the validator to shut up. How about a validator interface along the lines of: I see you've used a meta name=kapow tag. kapow isn't a meta name that I know about. Are you sure that it's a correct name, and that it's doing something useful in your document? If so, please tell me its purpose here, then I'll know what it's for and I won't complain about it again: __ Then the validator could add a wiki entry for it. 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/
Re: [whatwg] Proposal: Change HTML spec to allow any arbitrary value for the meta name attribute
On 04/06/2013 11:08 , Smylers wrote: Michael[tm] Smith writes: Speaking from my perspective as a contributor to development of a conformance checker: In practice, we receive a lot of comments and bug reports from confused/frustrated users who are trying to use values for meta@name that are not registered. Hi Mike. Thanks for sharing your wisdom on this. 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. And do you have an idea which user-agents are acting on those names? I am not aware of specific cases in which the browser is acting on the names, but there are quite a few in which a third-party system is (e.g. when using those as checks that a given person really has access to a given site). The point is often that the person seeing the validity error is not the same person who defined the metadata name. Yes, you can register on behalf of someone else, but it's a hurdle and it's not the right social mechanics. It doesn't seem to buy anyone much, either. I'm interested in whether the meta tags people are using are meaningless cruft or have useful effects in niche fields. They're not cruft, they're product-specific. In many cases some data-* attributes would be better, but they're not what's used. And as far as the strategy of trying to use the spec and Wiki page as a means to educate them about trying to taking the time to register meta@name values and only use registered values and standard values (those listed in the spec), well, that strategy is not working well. They just want the validator to shut up. How about a validator interface along the lines of: I see you've used a meta name=kapow tag. kapow isn't a meta name that I know about. Are you sure that it's a correct name, and that it's doing something useful in your document? If so, please tell me its purpose here, then I'll know what it's for and I won't complain about it again: __ Then the validator could add a wiki entry for it. Going that far might be a bit much, but if there concern is that typos in names then a warning should do the trick. -- Robin Berjon - http://berjon.com/ - @robinberjon
Re: [whatwg] Proposal: Change HTML spec to allow any arbitrary value for the meta name attribute
On Tue, 04 Jun 2013 12:03:58 +0200, Robin Berjon ro...@w3.org wrote: 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. https://www.w3.org/Bugs/Public/show_bug.cgi?id=21916 -- Simon Pieters Opera Software
Re: [whatwg] Proposal: Change HTML spec to allow any arbitrary value for the meta name attribute
On 04/06/2013 12:24 , Simon Pieters wrote: On Tue, 04 Jun 2013 12:03:58 +0200, Robin Berjon ro...@w3.org wrote: 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. https://www.w3.org/Bugs/Public/show_bug.cgi?id=21916 Yes, I'm well aware. I even have a patch for that bug. It was just the first example that came to mind; meta is often the first thing that developers reach for. If the validation errors on metadata names served a clearly useful purpose I'd suggest waiting it out until using data-* becomes more of a reflex, but that doesn't seem to be the case so the pain inflicted in the meantime doesn't appear to be useful. -- Robin Berjon - http://berjon.com/ - @robinberjon
Re: [whatwg] Proposal: Change HTML spec to allow any arbitrary value for the meta name attribute
On Tue, Jun 4, 2013 at 11:33 AM, Robin Berjon ro...@w3.org wrote: Yes, I'm well aware. I even have a patch for that bug. It was just the first example that came to mind; meta is often the first thing that developers reach for. If the validation errors on metadata names served a clearly useful purpose I'd suggest waiting it out until using data-* becomes more of a reflex, but that doesn't seem to be the case so the pain inflicted in the meantime doesn't appear to be useful. It seems conceptually problematic for something to be both semantically similar to data-* and say element names, but in practice meta name seems to work okay. I think there might still be some value in the registry though and enforcing requirements for the names that are shared globally (gives developers feedback as to whether their meta elements might get incorrectly processed by software), and maybe issuing a warning for names not registered (you might have made an unintentional typo or you might want it registered for better validation). -- http://annevankesteren.nl/
Re: [whatwg] Proposal: Change HTML spec to allow any arbitrary value for the meta name attribute
On 4.6.2013 12:33, Robin Berjon wrote: developers reach for. If the validation errors on metadata names served a clearly useful purpose I'd suggest waiting it out until using data-* becomes more of a reflex, but that doesn't seem to be the case so the pain inflicted in the meantime doesn't appear to be useful. I think that spec is not really not good in this aspect and should be changed along the lines Mike proposed. The spec should allow any name and validator optionally could emit warning if unregistered name is used. But it shouldn't be treated as error -- meta was always extension point and it's unrealistic to think that every piece of metadata will go to registry. Jirka div data-gi=could-not-resist If there would be real distributed extensibility on metadata names... /div -- -- Jirka Kosek e-mail: ji...@kosek.cz http://xmlguru.cz -- Professional XML consulting and training services DocBook customization, custom XSLT/XSL-FO document processing -- OASIS DocBook TC member, W3C Invited Expert, ISO JTC1/SC34 rep. -- Bringing you XML Prague conferencehttp://xmlprague.cz --
Re: [whatwg] Proposal: Change HTML spec to allow any arbitrary value for the meta name attribute
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@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/
