https://html.spec.whatwg.org/multipage/webappapis.html#custom-handlers
scheme (registerProtocolHandler() only)
Would it be possible to safelist protocol handlers for gps locations for use on maps etc? I would prefer to assign these to the web based map of choosing instead of the built in applications.
map:
gmap:
bingmap:
location:
and possibly others?
I personally think this makes sense, but we've had resistance from browser implementers when trying to accept such expansions of the safelist in the past: see https://github.com/whatwg/html/pull/1829 and https://github.com/whatwg/html/issues/2204 for example. I reached out internally to some Chrome devs and they weren't happy about expanding it. So I'm not sure what to do about this feature :-/ It seems like in practice the spec's promise that we can expand the scheme list is not bearing out.
@domenic do you know why they're not happy? Feature isn't used enough?
I can try to get them to comment publicly but: it seems like they did not see any immediate trouble with git:, but had security concerns about web-based optauth: apps, which didn't make much sense to me. Since they didn't make much sense, it's hard for me to predict when they would be applied, e.g. maybe they have the same security concerns around mapping and location.
It does seem like getting implementer interest is tricky here. E.g. I got the sense that even if we accepted #1829 based on Firefox using a blocklist and my Chrome colleagues' "I don't see any immediate trouble there", it's not exactly going on anyone's priority list to implement the safelist expansion.
Anyway I'll try poking people again to comment on this thread; it's good to re-start the discussion.
Yeah, I think the main problem is the lack of interest in this overall feature, which is a bit of a shame.
Some of the issues raised over at the Blink Intent-to-implement thread and discussions around it:
gmap and bingmap are too vendor specific. Also it seems bingmaps is what Bing actually uses.location sounds redundant with geo RFC 5870 which is already whitelisted. Also the term location is super overloaded. Will probably lead to confusion.I'd be inclined to state that we'll add gmap or bingmaps if the relevant vendors request them, and drop location in favor of geo.
This leaves map. But the IANA registry has a provisional entry for maps (Registration details). I'd suggest going with maps instead of map here.
What do you think?
It does seem like this would be helped by @beikeland telling us what application he was actually building and needed these for. Given that some of the schemes are inaccurate, it's not clear whether the OP was a web developer planning to use these concrete schemes, or a vague feature request. If it was the latter, perhaps we should close this request.
Are all of these schemes equivalent ? What I'm asking is: why shouldn't there be just one scheme? I.e. geo?
Closing due to lack of response to feedback.
Most helpful comment
Some of the issues raised over at the Blink Intent-to-implement thread and discussions around it:
gmapandbingmapare too vendor specific. Also it seemsbingmapsis what Bing actually uses.locationsounds redundant withgeoRFC 5870 which is already whitelisted. Also the termlocationis super overloaded. Will probably lead to confusion.I'd be inclined to state that we'll add
gmaporbingmapsif the relevant vendors request them, and droplocationin favor ofgeo.This leaves
map. But the IANA registry has a provisional entry formaps(Registration details). I'd suggest going withmapsinstead ofmaphere.What do you think?