W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2012

Re: [IndexedDB] Problems unprefixing IndexedDB

From: Aryeh Gregor <ayg@aryeh.name>
Date: Fri, 10 Aug 2012 09:31:24 +0300
Message-ID: <CAKA+AxniTRKKsn7Vcxu=Br1az6p8ydhbnMQs=uwKZHyBgSE3EQ@mail.gmail.com>
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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:54 GMT