Re: [whatwg] Proposal: navigator.launchURL

On Mon, Jul 14, 2014 at 2:10 PM, Ian Hickson <ian@hixie.ch> wrote:
> On Mon, 14 Jul 2014, Adam Barth wrote:
>> The difference is that window.open opens a new browser window even if
>> the URL is handled by an external protocol handler.  Even if we changing
>> current browsers to detect whether the URL will be handled by an
>> external protocol handler before opening the window, web sites won't be
>> able to feature-detect which browsers have this new behavior and
>> therefore won't be able to move away from iframe@src hacks until all the
>> browsers they care about have the behavior change.  By contrast, sites
>> can feature detect navigator.launchURL and fall back to iframe@src in
>> UAs that lack the new API.
>
> I'm skeptical of features that only have a benefit during a short
> transition phase. Suppose it's five years from now and now everyone
> implements window.open() in this cleaner way and everyone also has
> launchURL(). Why is it good that we have both?

You're presupposing a particular series of future events.  It's more
likely that it will take longer than five years.  As an example, we
shipped unprefixed support for border-radius in May 2010, and browser
support is still only ~85% of traffic:

http://caniuse.com/#search=border-radius

If web developers need to wait for the long tail of browsers to catch
up before they can use a feature, they're unlikely to adopt it.  If
developers don't adopt a feature, browser vendors are less likely to
adopt the feature.  That's why the bootstrapping process is an
important consideration.

Adam

Received on Monday, 14 July 2014 21:33:29 UTC