- From: Adam Barth <w3c@adambarth.com>
- Date: Mon, 14 Jul 2014 20:48:27 -0700
- To: Ian Hickson <ian@hixie.ch>
- Cc: whatwg@whatwg.org
On Mon, Jul 14, 2014 at 3:28 PM, Ian Hickson <ian@hixie.ch> wrote: > On Mon, 14 Jul 2014, Adam Barth wrote: >> > 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 > > It doesn't really matter how long it takes. The time until authors can > stop using the <iframe> hack is the same whether we provide a new API or > have a legacy API that needs updating to be slightly less annoying. > > >> 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. > > They can use window.open() today. It's just that it causes a bit of > flicker for now. IMHO the flicker is just a bug we should fix. > > Introducing a new API that literally doesn't do anything you can't already > do is a pretty high cost, IMHO. Ok, we can try the window.open approach first. Adam
Received on Tuesday, 15 July 2014 03:49:25 UTC