On 2012-11-12 6:01 AM, Henri Sivonen wrote:
On Fri, Nov 9, 2012 at 10:32 PM, Ehsan Akhgari <ehsan.akhg...@gmail.com> wrote:
Sort of. Well, from time to time we add a new DOM API which breaks a
website because they expect that name to be available as an expando property
or something.
Prefixing doesn't fix this problem. It only defers it, which (I think)
is worse than finding incompatibilities early on and changing the
names in the spec not to collide with what’s already used out there.
I agree. Prefixing in practice is really just a way to make us feel
better about breaking something which we have shipped before, and that's
bad for web developers. But this is sort of an orthogonal discussion.
But that's not really important, I'm mostly concerned about
the stuff that we will ship in the future. The specific thing that I'm
worried about is Web Audio which is a huge spec and we may not be able to
implement all of it for quite a while for a variety of reasons, and it might
be difficult to decide whether implementing more of it will break existing
users, because, among other things, the spec is also changing.
If a spec is actively changing in breaking ways, we shouldn’t ship an
implementation to the release channel. OTOH, once an implementation
has been shipped to the release channel and Web content depends on in,
a reasonable spec editor won’t make breaking changes anymore.
So if we agree that breaking changes are still necessary, we shouldn’t
ship. If we think we need to ship, we need to tell the spec editor not
to make breaking changes anymore.
I'm not sure if that call can be made easily in all cases. There might
be parts of a given spec that we don't want to implement because they
are bad ideas, and while we try to fix them in the spec, doing so is not
always possible. Our position on such types of issues might change
because web developers may start depending on those features to an
extent where we have to implement them, and I'm afraid that with the
policy you're proposing, such cases may prevent us from shipping a
feature to the release channel unprefixed for an extended period of time.
Cheers,
Ehsan
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
