W3C home > Mailing lists > Public > whatwg@whatwg.org > July 2014

Re: [whatwg] Proposal: navigator.launchURL

From: Adam Barth <w3c@adambarth.com>
Date: Mon, 14 Jul 2014 14:32:12 -0700
Message-ID: <CAJE5ia_PR0VYMkf0ms8VWXzo+=HkYypRFEd-iDR67gRaa=ivgA@mail.gmail.com>
To: Ian Hickson <ian@hixie.ch>
Cc: whatwg@whatwg.org
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:


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.

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

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:21 UTC