New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Drop requirement to register meta[name] extensions #2229

Merged
merged 4 commits into from Feb 8, 2017

Conversation

@sideshowbarker
Member

sideshowbarker commented Jan 2, 2017

The original spirit behind the requirement to register meta[name] extensions
was 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 10
months 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.

@zcorpan

This comment has been minimized.

Member

zcorpan commented Jan 2, 2017

I assume the benefit would be that the checker can point out typos in the name or value? Did you evaluate the effectiveness of that before dropping it from the checker?

The wiki also has 2 values that are "Unendorsed"; should we make them "must not"s?

cc @hsivonen

@sideshowbarker

This comment has been minimized.

Member

sideshowbarker commented Jan 2, 2017

I assume the benefit would be that the checker can point out typos in the name or value? Did you evaluate the effectiveness of that before dropping it from the checker?

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.

@hsivonen

This comment has been minimized.

Member

hsivonen commented Jan 2, 2017

Most values registered at https://wiki.whatwg.org/wiki/MetaExtensions are
essentially for private use for only the people/organizations who minted them,

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.)

and have zero general utility and no public applications that consume them.

This is likely for stuff that's not Microsoft/Facebook/Twitter/Apple/Google-sensitive.

For authors, catching typos is the only real benefit of the registration requirement.

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 apple- or dc.. That wouldn't catch typos if the typos are in the prefix itself, of course.

@sideshowbarker

This comment has been minimized.

Member

sideshowbarker commented Jan 2, 2017

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.)

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.

and have zero general utility and no public applications that consume them.

This is likely for stuff that's not Microsoft/Facebook/Twitter/Apple/Google-sensitive.

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 meta elements for all kinds of stuff that didn’t seem to be very useful or necessary.

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.

@domenic

This comment has been minimized.

Member

domenic commented Jan 2, 2017

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 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.

The benefits, summarizing Hixie's emails, are largely:

  • Creating a registry documenting what's out there
  • Helping authors catch typos
  • Helping authors and communities consolidate around a more canonical set of names

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.

@zcorpan

This comment has been minimized.

Member

zcorpan commented Jan 3, 2017

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 rel extensions? Also just allow anything also? http://microformats.org/wiki/existing-rel-values#HTML5_link_type_extensions cc @tantek

I guess it is always possible to pick up @Hixie's proposal later, or come up with something else...

@sideshowbarker

This comment has been minimized.

Member

sideshowbarker commented Jan 3, 2017

I understand that the current situation is frustrating

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.

especially when the wiki is broken. :-) But I'm curious what the bigger plan is.

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 table[sortable] that followed it later) and so on did not.

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.

What do we want to do with rel extensions? Also just allow anything also? http://microformats.org/wiki/existing-rel-values#HTML5_link_type_extensions

That’s kind of a red herring. It’s different/separate from the meta name situation. There’s a much smaller set of registered rel values, they’re basically sane values and people do not seem to be going in there and just dumping things. And the checker supports checking that registry and I have no plans to make it stop doing that any time soon. So I see no need to make any spec change there.

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.

@annevk

This comment has been minimized.

Member

annevk commented Jan 3, 2017

What is the story for standard metadata names? It seems <meta name=referrer> can be usefully checked by an HTML checker. Same for <meta name=theme-color>. Having a registry also helps us avoid picking already used names as standard metadata names.

@zcorpan

This comment has been minimized.

Member

zcorpan commented Jan 3, 2017

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 viewport), and should be checked by the checker in my opinion.

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.

@annevk

This comment has been minimized.

Member

annevk commented Jan 3, 2017

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>

This comment has been minimized.

@zcorpan

zcorpan Jan 3, 2017

Member
+  <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.

@sideshowbarker

This comment has been minimized.

Member

sideshowbarker commented Jan 3, 2017

What is the story for standard metadata names? It seems <meta name=referrer> can be usefully checked by an HTML checker. Same for <meta name=theme-color>.

The story is that we can’t both check for typos in those while also allowing arbitrary values.
The checker allows arbitrary values so that means we are not able to check for typos currently.

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 meta[name] values is of a high enough priority to authors to merit the observably high cost of at the same time imposing a registration requirement on them if they want to use non-standard values.

Incidentally, this is why IMHO it was bad idea to ever standardize any meta[name] values to begin with. In hindsight, we should have realized it doesn’t work out well to make something serve both for stating standard properties and at the same time make it an open-ended extension point.

That is why I am especially sad about meta[name=theme-color] and meta[name=referrer]. It as a mistake to have shoehorned those into the meta element. Anything that has UA requirements is too important to drop into a grab-bag like meta.

So the real problem is, we chose to hang the theme-color feature and the referrer-policy feature on meta. We unfortunately can’t unwind that decision now, and I wish we could mitigate the problem of authors mistyping markup for those, but unfortunately because of the choice we made to use meta as the markup mechanism, the tradeoff is that we lose ability to help catch those typos.

(And yeah a lot of the above could also be said about link[rel] but in practice that has fortunately not (yet) degraded into as much of a broken state.)

@annevk

This comment has been minimized.

Member

annevk commented Jan 3, 2017

Given that, we should probably discourage user agents from implementing any new <meta name> values in the standard.

@zcorpan

This comment has been minimized.

Member

zcorpan commented Jan 3, 2017

@sideshowbarker we can still check the content attribute when the name is one of the standard names.

@sideshowbarker

This comment has been minimized.

Member

sideshowbarker commented Jan 3, 2017

The keywords with multi-vendor UA processing should be in the spec (like viewport), and should be checked by the checker in my opinion.

@sideshowbarker we can still check the content attribute when the name is one of the standard names.

Yes, agreed. And there’s already code in the checker for checking, e.g., the “There must not be more than one meta element with its name attribute set to the value description per document” requirement in the spec.

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.

@sideshowbarker

This comment has been minimized.

Member

sideshowbarker commented Jan 3, 2017

Given that, we should probably discourage user agents from implementing any new <meta name> values in the standard.

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 meta[name=theme-color] and meta[name=referrer] as far as speaking up about them myself when they came along. Wish now I had.

@sideshowbarker

This comment has been minimized.

Member

sideshowbarker commented Jan 3, 2017

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?

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.

@domenic

This comment has been minimized.

Member

domenic commented Jan 3, 2017

Hmm, I'm not sure I agree that UAs should not be using meta name as an extension point for UA processing features. What would the alternative be? I understand it's problematic in that it might collide with things already in use in the wild, but it's worked pretty OK so far...


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:

  • browser-specific pragmas (apple-*, msapplication-*)
  • Pragmas and vocabularies for other software (googlebot, google-site-verification, pingdom, pinterest, twitter:*, ...)
  • Domain-specific vocabularies (AGLSTERMS.*, bug.*, citation_*, ... most everything with a namespace).
  • Maybe general metadata vocabularies (dcterms.*)?
  • Probably more...

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.

@sideshowbarker

This comment has been minimized.

Member

sideshowbarker commented Jan 4, 2017

Hmm, I'm not sure I agree that UAs should not be using meta name as an extension point for UA processing features. What would the alternative be?

meta[http-equiv]. In the case of both meta[name=referrer] and meta[name=theme-color] it’s not clear whether that was ever even considered—and if it was considered, why it was rejected.

But if some future case meta[http-equiv] is considered but it’s determined it won’t work for some reason, then I still think other alternatives should be explored before meta[name] is used.

It’s not like meta[name] has forever been a thing with UA processing requirements. Before we introduced meta[name=referrer] and meta[name=theme-color], there were no UAs that did any processing of meta[name] values.

Instead before meta[name=referrer] and meta[name=theme-color], meta[name] was essentially just an open extension point, with a handful of the values that are in common use for it documented in the spec. It shared the characteristic with class of being (in practice) something where we intentionally never dropped in properties that had any standard UA requirements.

But given that we broke that property of it by adding meta[name=referrer] and meta[name=theme-color], I guess maybe it’s a lost cause now and it doesn’t matter how many more similar values with UA requirements we might add to it going forward.

@sideshowbarker

This comment has been minimized.

Member

sideshowbarker commented Jan 4, 2017

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.

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.

Maybe if someone paid a lot of attention to curating it
But this is again a decent amount of work that nobody seems interested in

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.

@annevk

This comment has been minimized.

Member

annevk commented Jan 4, 2017

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.

@zcorpan

This comment has been minimized.

Member

zcorpan commented Jan 4, 2017

Before we introduced meta[name=referrer] and meta[name=theme-color], there were no UAs that did any processing of meta[name] values.

You're forgetting about viewport and application-name, at least.

http-equiv has the effect of making people (web developers and browser implementors alike) that there will/should be an HTTP header also that does the same thing.

But an alternative going forward could be to mint new attributes for each feature.

<meta newfeature="value">

@sideshowbarker sideshowbarker force-pushed the sideshowbarker/drop-meta-name-registration branch from 17a59a3 to d82c4e0 Jan 8, 2017

Drop requirement to register meta[name] extensions
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 sideshowbarker force-pushed the sideshowbarker/drop-meta-name-registration branch from d82c4e0 to de53c29 Jan 8, 2017

@sideshowbarker

This comment has been minimized.

Member

sideshowbarker commented Jan 8, 2017

OK, de53c29 is an amended commit that attempts to address all review feedback that has been posted in comments here.

@zcorpan

zcorpan approved these changes Jan 9, 2017

Lgtm. It is still an open issue what UAs should do for new extensions; can you file a new issue for that?

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>

This comment has been minimized.

@annevk

annevk Jan 9, 2017

Member

You mean metadata value, right?

This comment has been minimized.

@annevk

annevk Jan 9, 2017

Member

This is basically the requirement that you remove below, but restated to be less of a requirement.

This comment has been minimized.

@sideshowbarker

sideshowbarker Feb 5, 2017

Member
+  <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).“

This comment has been minimized.

@annevk

annevk Feb 7, 2017

Member

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>

This comment has been minimized.

@annevk

annevk Jan 9, 2017

Member

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>

This comment has been minimized.

@annevk

annevk Jan 9, 2017

Member

Spaces again. s/actually// s/unnecessarily//

There's a third reason. To avoid new standardized names clashing with your chosen name.

This comment has been minimized.

@sideshowbarker

sideshowbarker Feb 5, 2017

Member

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>

This comment has been minimized.

@annevk

annevk Jan 9, 2017

Member

What is the other use again? Should this not basically just not be used?

This comment has been minimized.

@sideshowbarker

sideshowbarker Feb 5, 2017

Member

[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.”

@domenic

domenic approved these changes Jan 9, 2017

LGTM with @annevk's nits addressed

@zcorpan zcorpan assigned annevk and unassigned sideshowbarker Feb 6, 2017

@annevk

This comment has been minimized.

Member

annevk commented Feb 7, 2017

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.

@sideshowbarker

This comment has been minimized.

Member

sideshowbarker commented Feb 8, 2017

It is still an open issue what UAs should do for new extensions; can you file a new issue for that?

Raised #2335 for that

sideshowbarker and others added some commits Feb 8, 2017

@annevk

annevk approved these changes Feb 8, 2017

@annevk

This comment has been minimized.

Member

annevk commented Feb 8, 2017

@sideshowbarker fiddled a little more with it. LGTM now, but you should check.

@sideshowbarker

This comment has been minimized.

Member

sideshowbarker commented Feb 8, 2017

@sideshowbarker fiddled a little more with it. LGTM now, but you should check.

Changes LGTM

@annevk annevk merged commit 92eb704 into master Feb 8, 2017

2 checks passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
continuous-integration/travis-ci/push The Travis CI build passed
Details

@annevk annevk deleted the sideshowbarker/drop-meta-name-registration branch Feb 8, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment