776001 - Unprefix the EXT_texture_filter_anisotropic extension

Status: RESOLVED FIXED

(Core :: Graphics: CanvasWebGL, defect)

Description

[Benoit Jacob [:bjacob] (mostly away)]

EXT_texture_filter_anisotropic has just received "community approved" status.

This means that browsers may now implement it unprefixed.

We should unprefix it as soon as possible to be good Web citizens. Not even keeping the prefixed name around --- users of prefixed WebGL extension can be required to adapt to prefix removal.

Comment 1

[Benoit Jacob [:bjacob] (mostly away)]

Attachment: remove MOZ_EXT_texture_filter_anisotropic prefix

Comment 2

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Comment on attachment 644364 [details] [diff] [review]
remove MOZ_EXT_texture_filter_anisotropic prefix

We shipped it with the MOZ prefix, right?  I wonder if we should have one release cycle where both are around, but the MOZ-prefixed one warns that it's going away?

Comment 3

[Benoit Jacob [:bjacob] (mostly away)]

I really don't think we should start making this kind of stability commitments for vendor prefixes. I feel much more comfortable about keeping hammering to webdevs the notion that if they're going to use vendor-prefixed extensions, they should be ready for them to go away at any time (probably by testing their apps in beta versions of browsers at least).

Comment 4

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

That's very different from the general case of web APIs, where prefixes carry forward almost forever.  It's not a great situation, but neither is making an app that works great and uses a vendor extension for some nice feature... then that extension happens to take a year to get finalized and unprefixed, and now the app that's been working fine for over a year no longer works/supports the feature?  That seems like a pretty crappy situation.  It's also the reason why GL keeps supporting all the prefixes of an extension even after they're in core or moved to ARB.

Actually, thinking about it that way, I'd say we just shouldn't drop support for the MOZ prefix at all...

Comment 5

[Benoit Jacob [:bjacob] (mostly away)]

One can't compare WebGL vendor prefixes to OpenGL vendor prefixes because of this fundamental difference: WebGL vendor prefixes are vendor monopolies, contrary to OpenGL vendor prefixes which other vendors are allowed to implement.

So it will suck if removing a vendor prefix breaks a real-world app, but that is still a hypothetical case: it really isn't hard for app developers to remove these 4 characters, MOZ_, from their source code, and so it isn't clear to me that real problems will happen.

On the other hand, the problems with Web APIs vendor prefixes are so real, that a few months ago with CSS we went very close to stopping honoring the "don't implement other vendors' prefixes" rule:
  http://hsivonen.iki.fi/vendor-prefixes/

And indeed, we are still struggling to get a foothold on the Mobile Web due to sites targeting WebKit and CSS vendor prefixes are still a big part of that (not _all_ of that. But a big part, and one that we can't solve at all ourselves besides evangelizing, because we are not even allowed to implement other vendors' prefixes.)

To summarize:
 - the Web way to vendor prefixes is locking the browser engine market
 - the OpenGL way to vendor prefixes is just fine
 - unfortunately WebGL uses the Web way, not the OpenGL way
 - therefore, I'd much rather get rid of WebGL vendor prefixes as early as possible during an extension's lifecycle.

Comment 6

[Benoit Jacob [:bjacob] (mostly away)]

Summarizing a conversation with Vlad+Jeff+others:
 - as a short-term compromise we can do what Vlad suggested in comment 2
 - another approach is to say, since in this case there were no difference between the different vendor-prefixed versions and the unprefixed version is still exactly the same, we could (discuss with the WG) allow to implement each other's vendor prefix.
 - conversely, since this extension was never going to be contentious anyway, we could have done it unprefixed or using a multi-vendor prefix since the beginning.
 - a more radical idea would be to switch to the OpenGL model wholesale.

Comment 7

[Benoit Jacob [:bjacob] (mostly away)]

Attachment: Support EXT_texture_filter_anisotropic without prefix; warn on using the MOZ_ prefix

Comment 8

[Benoit Jacob [:bjacob] (mostly away)]

http://hg.mozilla.org/integration/mozilla-inbound/rev/e5e8d176ac96

Comment 9

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/e5e8d176ac96