- From: Aryeh Gregor <ayg@aryeh.name>
- Date: Fri, 10 Aug 2012 09:31:24 +0300
- To: Glenn Maynard <glenn@zewt.org>
- Cc: "L. David Baron" <dbaron@dbaron.org>, public-webapps@w3.org
On Fri, Aug 10, 2012 at 5:47 AM, Glenn Maynard <glenn@zewt.org> wrote: > That makes it impossible for *anyone* to avoid breakage (unless they add the > unprefixed version before unprefixing happens). You're exchanging avoidable > breakage for unavoidable breakage, which doesn't make sense. It's not unavoidable. You just have to future-proof your code. For instance: if (!("indexedDB" in window)) { window.indexedDB = "webkitIndexedDB" in window ? window.webkitIndexedDB : "mozIndexedDB" in window ? window.mozIndexedDB : ... } So it's possible, but authors probably won't do it, because it's not necessary to get their pages to work. So I reiterate that what makes sense is just not to ship prefixed features in stable browser versions at all. Experience has clearly shown that authors just paper over the prefixes anyway -- in CSS they repeat the exact same declaration for each prefix, and in JavaScript they do something like the above. This basically eliminates any benefit of prefixing, since what authors do is equivalent to all browsers using the same property name anyway, except it's worse in a few ways: 1) It makes it harder for authors to use the feature. They have to add extra lines of JS, or specify the same CSS repeatedly. 2) Authors might omit the unprefixed property, since initially it won't hurt anything, and there are those who encourage them to do so. This means that either browsers support the prefixed versions forever, or they break some pages. 3) Authors won't necessarily account for all prefixes. This disadvantages minor browsers, or those who add support for the feature later -- unless they start recognizing their competitors' prefixes, which just makes the entire convention even more of a farce than it already is. This means we're stuck with a permanent reduction in interop: there will always be some pages that will work in some browsers but not others, because they don't specify the full set of prefixes. (This would only be fixed if either all browsers recognized all prefixes, so that such pages would work in all browsers; or no browser recognized any prefix, so that such pages would break in all browsers.) The short version of the story is: everyone should stop shipping any new prefixed properties in stable builds, now. (Unstable builds are probably fine if they have few enough users, like maybe Aurora/nightly for Firefox or dev for Chrome, because then not many pages will use the feature.) And for existing properties that were already shipped with prefixes, everyone should recognize all known prefixed variants, plus the unprefixed variant, and keep that support forever. (Since most browsers are not going to drop support for their own prefix, so there's no other way to get interop.) But this has been discussed to death on standards fora, and no one has reached agreement, so it's up to individual browsers to act as they see fit. Fortunately, at least Firefox now seems set to not ship any new prefixed CSS properties in stable releases. I hope that policy will apply to non-CSS features too going forward. For the immediate problem, my personal opinion would be that Gecko should make mozIndexedDB a permanent alias of indexedDB -- *along* with msIndexedDB and webkitIndexedDB, with a console warning if the prefixed properties are accessed saying that the aliases are nonstandard. That makes as many pages as possible work. On the other hand, it also doesn't disadvantage other browsers by favoring pages that use mozIndexedDB.
Received on Friday, 10 August 2012 06:32:14 UTC