- From: Ian Hickson <ian@hixie.ch>
- Date: Mon, 14 Jul 2014 22:28:39 +0000 (UTC)
- To: Adam Barth <w3c@adambarth.com>
- Cc: whatwg@whatwg.org
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. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Monday, 14 July 2014 22:29:04 UTC