Drop requirement to register meta[name] extensions #2229
Conversation
|
I assume the benefit would be that the checker can point out typos in the The wiki also has 2 values that are "Unendorsed"; should we make them "must not"s? cc @hsivonen |
I did evaluate it. For authors, catching typos is the only real benefit of the registration requirement. But that benefit—which would in this case at best be of relatively marginal value even if this had not become the mess it’s evolved into—is far outweighed by the cost of dealing with the registration mechanism, especially the cost of us (mostly me) needing to field requests from people who want wiki accounts for the sole purpose of adding new meta name values to the MetaExtensions page at the wiki. (And these days I seem to be the only one who takes time to respond to those requests.) Case in point: somebody sent a new-account request today, and as usual it was just so they could add to the MetaExtensions page. https://wiki.whatwg.org/wiki/Special:Log/newusers And when people do add new values there, the values they add are nearly always useless to anybody else or that duplicate values others have already added. Case in point: The new values added just today: https://wiki.whatwg.org/index.php?title=MetaExtensions&curid=1655&diff=10144&oldid=10111 That’s the overwhelming pattern. There are currently 356 values that have been added there, and I challenge anybody to go in there and identify any more than a dozen or two of them that they recognize or that seem like anybody except the people who dumped them in there are using. So to answer you’re question, I’ve done my due diligence on this. This requirement has already cost vastly more of my time than it merits and going forward I want to reduce the time it costs me or anybody else to zero. And the way to try to get it to zero is to stop encouraging authors to go through the process of registering new values, which has basically become an entirely pointless exercise in wasting their own time and ours. So let’s please stop it. |
A rather large proportion purports to be general use (Dublin Core and similar geo stuff) or is sensitive to widely-used vendor-specific agents (Safari on iOS, Twitter, etc.)
This is likely for stuff that's not Microsoft/Facebook/Twitter/Apple/Google-sensitive.
I wonder if it's practical to catch typos by checking a list of permitted values if the token starts with a well-known prefix like |
I count that among the dozen or two I alluded to in my earlier comments here. Though I concede the list of Dublin Core values is long, but I conceive of it more as a single logical set among the dozens and dozens of others there that don’t actually have any real perceivable footprint on the Web.
Sure, and that’s fine of course. But from that fact it does not follow that there’s any real value to requiring registration for those—neither to the people who minted them not to authors in general. It seems like in part we may have lost track of the problem we were trying to solve by adding the registration requirement. As I remember though, the main problem (or one of them at least) was to try to reduce the proliferation of junk values being used by authors—loading up of documents with multiple But we still have that problem. The thing is, many of those values that don’t seem to have any clear utility are now registered. Another idea of what would happen once we started to require registration was that authors would quit putting useless values into their docs—because the checker would flag them as errors—and would remove existing useless values from their docs. But I don’t think we have much evidence that’s ever happened. Instead I think for the most part, the authors just ignore the checker “errors” for values that they want to use, and they do not bother to take the time to jump through the hoops of requesting a wiki account and adding their values. To be clear, I have no problem with authors using values in their documents that aren’t Microsoft/Facebook/Twitter/Apple/Google-sensitive. But I think the current spec requirement in practice actually discourages them from doing that. And I have personally have zero interest in investing any more time than I already have to police or curate what values should be allowed. So I think simply dropping the requirement from the spec leaves authors at the very least not any worse off than they are now—and in fact IMHO it makes things actually better for them. |
|
Related:
In general I think the motivation behind the current system is good, and @Hixie's proposed ambitious revamp would probably add value to peoples' lives (although I didn't read the replies to it). I like the fact that
The benefits, summarizing Hixie's emails, are largely:
But we have to face the facts that the time invested vs. these benefits doesn't seem to be working out. @Hixie's proposal has some ideas for how we can more easily achieve these benefits while avoiding some of the existing pitfalls, but in the end it's a medium-sized software engineering project that I don't think any of us are signing up for. In conclusion, I see both sides of the issue, but in the end I trust @sideshowbarker's judgement as someone who's been on the front lines. I'm curious to hear what others think. |
|
I understand that the current situation is frustrating, especially when the wiki is broken. :-) But I'm curious what the bigger plan is. What do we want to do with I guess it is always possible to pick up @Hixie's proposal later, or come up with something else... |
It’s not about frustration. It’s about time being wasted over years now on something, however well-intended, that doesn’t actually seem to be solving any real problem.
I think it is not clear that a bigger plan is necessary for meta name. The original plan was an aspirational one introduced in the Web Apps 1.0 days when there were a lot of other cool aspirational ideas that got specced. Most of them worked out massively well, and a few others like DataGrid (and And when it becomes clear there’s not enough real need from Web devs for one of those aspirational plans, and not enough interest from implementors, then we drop it and move on. Clearly we’ve done that a number of times in the last year or so with features in the spec that have not panned out. So this is one of those kinds of features. It just happens to have a different conformance class. I personally reached the point on seeing it that way more than 3 years ago now, when I sent this: https://lists.w3.org/Archives/Public/public-whatwg-archive/2013Jun/0007.html That’s the message @Hixie was replying to that’s cited earlier in this thread. Nothing around the situation has changed in the 3 years since. No community has emerged of people collaborating on sharing new ideas about meta name values for common use. The MetaExtensions page has instead largely just remained write-only, with people essentially just dumping stuff there and leaving, and nobody else even noticing that they added something. Tree falling in the woods.
That’s kind of a red herring. It’s different/separate from the meta name situation. There’s a much smaller set of registered I guess an argument could be made that if somebody tried to put a real community around the meta name registry and invested time in curating it, it might develop into something actually useful. If somebody wanted to take the time to try that, I think rather than keeping the registry in the wiki, it should be migrated to a GitHub repo and the mechanism for submitting new meta name values would be to create a PR. That way, others who care would get notified when somebody wanted to add something, and they could comment, and real discussions could take place, etc. If something like that ever were to develop to the point that it actually looked active and viable, then at the time I think it could make sense to consider re-adding a requirement to the spec. Paving the cowpath that got created out of it. And at that time I could similarly make sense to re-add support for it to the checker. But that is not where we are now. So for now we can drop the requirement from the spec without prejudice and instead let something develop out of it (or not) naturally, and re-evaluate it later as needed, just as with other features that have been dropped from the spec. |
|
What is the story for standard metadata names? It seems |
|
I now think it is reasonable to drop the registry requirement since it lacks implementor interest. The keywords with multi-vendor UA processing should be in the spec (like This change doesn't remove the wiki page, and doesn't prevent those interested in maintaining a registry to do so (wiki or otherwise). We can also search httparchive etc when minting new standard names. |
|
Should we keep a reference to the wiki page then and continue to consult that when minting new names or elevating names to be part of the standard? |
source
Outdated
| accepted. Links must be represented using the <code>link</code> element, not the <code>meta</code> | ||
| element.</p> | ||
| <p>Anyone can create and use their own <dfn data-x="concept-meta-extensions">extensions to the | ||
| predefined set of metadata names</dfn>. There is no requirement to register such extensions.</p> |
There was a problem hiding this comment.
+ <p>Anyone can create and use their own <dfn data-x="concept-meta-extensions">extensions to the
+ predefined set of metadata names</dfn>. There is no requirement to register such extensions.</p>I think this should have some caveats:
- When the intended value is a URL, encourage using
<link rel>instead.- Names that have UA processing should be proposed to be added to the spec so it can become a standard metadata name if there is enough interest from other vendors.
Yes, agreed. Will update the PR to add those refinements.
The story is that we can’t both check for typos in those while also allowing arbitrary values. Clearly we make tradeoffs all over the place in decisions in the design of features and requirements. This is one of those. I do not think that the value of catching typos in standard Incidentally, this is why IMHO it was bad idea to ever standardize any That is why I am especially sad about So the real problem is, we chose to hang the theme-color feature and the referrer-policy feature on (And yeah a lot of the above could also be said about |
|
Given that, we should probably discourage user agents from implementing any new |
|
@sideshowbarker we can still check the |
Yes, agreed. And there’s already code in the checker for checking, e.g., the “There must not be more than one So we’re OK there and no plans to change that and we can add checks for any similar future requirements like that which might come up. |
Yes, I hope we can keep a better eye on things going forward and make sure nobody creates more of these. I was kind of asleep at the switch on |
OK, I can revise the PR to restore that part (or some of it at least). But if we can going to continue to have something like that in the spec, then maybe we can consider what I alluded to earlier here about migrating it away from the wiki and to a GitHub repo. Because if we are to have a mechanism for this at all going forward, I think that doing it as a GitHub repo has a lot better characteristics. A least if the goal if for helping it work better for the people who would be contributing to it and the people using it. If that sounds like something we want to do, I can put time into setting up such a GitHub repo. I guess if others here think that would be a good idea, I can first raise an issue for discussing the details. |
|
Hmm, I'm not sure I agree that UAs should not be using Regarding whether we want to keep the content of https://wiki.whatwg.org/wiki/MetaExtensions around in some form... I don't know. Just looking through it, it contains so little useful information for web developers. Maybe if someone paid a lot of attention to curating it, and e.g. had sections like:
And in general the large vocabularies should get a single line of text/link instead of taking up all that space you have to scroll through. But this is again a decent amount of work that nobody seems interested in. I'm inclined to trust @sideshowbarker saying that it's a write-only dumping ground and we shouldn't spend any more time curating it. |
But if some future case It’s not like Instead before But given that we broke that property of it by adding |
Yeah, I think so too. That said, I am also sympathetic to the point of view @annevk and @zcorpan have advocated for about have some reference in the spec to a resource that developer-authors can “continue to consult when minting new names or elevating names to be part of the standard”. But I think the wiki page as currently realized is not meeting that need for users well at all—for reasons that I have mentioned in other comments here—while at the same time imposing a cost on us in terms needing to respond to requests for wiki accounts (which is admittedly a relatively small cost each time, but the effect of it accumulative—death by a thousand cuts and all that). Given all that, I have come back around to believing it would be counterproductive to retain mention of the current MetaExtensions wiki page/mechanism in the spec in its current form. I believe it’s better to have no mention at all of it in the spec unless/until we can get it replaced with something that is not broken. So what I think we should instead do is to go ahead and for now drop the current reference to it in the spec, but in parallel work on setting up a GitHub repo to replace it. Then once we have that in place, we can at that time then add back a reference to that in the spec. @annevk, @zcorpan it that acceptable to you? For my part as I’ve said earlier, I could put time into helping get that repo set up, and if others here think that having a repo would be a good idea, then I can go ahead and open an issue to discuss it.
I think we would have a better change of getting somebody interested if we constituted is as a GitHub repo instead. For one thing, some level of curation would then automatically just fall out from having done that, because the new process would then be to raise PRs that somebody would need to review before they got merged, and that others could comment on. |
|
MetaExtensions has been accessed well over a half a million times. It's not clear to me at all it's a write-only dumping ground. Just because we don't use it doesn't mean nobody else does either. For starters if you need mint such a name for your own software you might not want to collide with someone else and not have someone else collide with you in the future. It's clear that the HTML checker and user agents don't get much utility from it, but there's a wider community we don't really know much about. |
You're forgetting about
But an alternative going forward could be to mint new attributes for each feature. <meta newfeature="value"> |
sideshowbarker
force-pushed
the
sideshowbarker/drop-meta-name-registration
branch
from
17a59a3
to
d82c4e0
Compare
The original spirit behind the requirement to register meta[name] extensions was good, but in practice it has ended up costing a large of maintenance time without it being clear how much real benefit to end users it has provided. Many values listed at https://wiki.whatwg.org/wiki/MetaExtensions appear to be essentially for private use for only the people/organizations who minted them, without it being clear how much general utility they might have, and without any evidence of public applications that consume them. So this change drops the requirement to formally register new meta[name] names, while still retaining a reference to https://wiki.whatwg.org/wiki/MetaExtensions informatively—in order to encourage authors to consult that before creating and using any new meta[name] names.
sideshowbarker
force-pushed
the
sideshowbarker/drop-meta-name-registration
branch
from
d82c4e0
to
de53c29
Compare
|
OK, de53c29 is an amended commit that attempts to address all review feedback that has been posted in comments here. |
source
Outdated
| names must be specified with the following information:</p> | ||
| <p>However, if the anticipated metadata name is a <span>URL</span>, registering the value as an | ||
| <span data-x="concept-rel-extensions">extension to the predefined set of link types</span> instead | ||
| is encouraged.</p> |
There was a problem hiding this comment.
This is basically the requirement that you remove below, but restated to be less of a requirement.
There was a problem hiding this comment.
+ <p>However, if the anticipated metadata name is a <span>URL</span>, registering the value as an
+ <span data-x="concept-rel-extensions">extension to the predefined set of link types</span> instead
+ is encouraged.</p> No, it’s a different requirement, right? The one I removed was about registering meta name values. But the language about registering link rel values (which the spec still requires)—it’s saying, “Since the value is a URL, then rather than using meta name for this thing at all, use link rel instead (and register the URL as a rel value).“
There was a problem hiding this comment.
What if the meta name is not a URL, but the meta value is? Where do we encourage the link element then? It seems that went missing and it seems important to keep.
source
Outdated
| <p>Furthermore, if the anticipated metadata name is something expected to have processing | ||
| requirements in user agents, proposing it as a new <a href="#standard-metadata-names">standard | ||
| metadata name</a> instead is encouraged—to find out if there's enough interest among user-agent | ||
| implementors in actually implementing support for it.</p> |
There was a problem hiding this comment.
We use spaces around "—" (added to https://wiki.whatwg.org/wiki/Style). "User-agent implementors" -> "user agents".
source
Outdated
| href="https://wiki.whatwg.org/wiki/MetaExtensions">WHATWG Wiki MetaExtensions page</a> is | ||
| encouraged—to avoid choosing a metadata name that's actually already in use, and to avoid | ||
| unnecessarily duplicating the purpose of any metadata names that are already in use. <ref | ||
| spec=WHATWGWIKI></p> |
There was a problem hiding this comment.
Spaces again. s/actually// s/unnecessarily//
There's a third reason. To avoid new standardized names clashing with your chosen name.
There was a problem hiding this comment.
There's a third reason. To avoid new standardized names clashing with your chosen name.
Added
source
Outdated
| used in the document, unnecessary; omit it altogether, and <span | ||
| data-x="concept-meta-extensions">register the names</span>.</p></dd> | ||
| <dd><p>When used for declaring which <code>meta</code> terms are used in the document, | ||
| unnecessary; omit it altogether.</p></dd> |
There was a problem hiding this comment.
What is the other use again? Should this not basically just not be used?
There was a problem hiding this comment.
[about the profile attribute for the html element]
What is the other use again? Should this not basically just not be used?
OK, I changed it to just an unqualified “Unnecessary. Omit it altogether.”
|
I was also wondering if we should rewrite "Other metadata names" a bit more. The first paragraph is probably reasonable. I think the "However" should become a list of things when we encourage not to mint a new name (e.g., when the intended name/value is a URL or when it's to become a standard metadata name). Concluding with the wiki also seems reasonable. |
Raised #2335 for that |
|
@sideshowbarker fiddled a little more with it. LGTM now, but you should check. |
Changes LGTM |
The original spirit behind the requirement to register
meta[name]extensionswas good but in practice, it has ended up costing a huge amount of maintenance
time for something that's produced almost no real benefit to end users.
Most values registered at https://wiki.whatwg.org/wiki/MetaExtensions are
essentially for private use for only the people/organizations who minted them,
and have zero general utility and no public applications that consume them.
So the HTML checker quit emitting errors for unregistered
meta[name]values 10months ago and there are no plans to re-add that reporting to it ever again. So
this is a case where the spec requirement is essentially a fiction, since the
main intended implementor of the requirement is wilfully choosing to ignore it.