Last Comment Bug 776001 - Unprefix the EXT_texture_filter_anisotropic extension
: Unprefix the EXT_texture_filter_anisotropic extension
Status: RESOLVED FIXED
:
Product: Core
Classification: Components
Component: Canvas: WebGL (show other bugs)
: unspecified
: All All
: -- normal (vote)
: mozilla17
Assigned To: Benoit Jacob [:bjacob] (mostly away)
:
: Milan Sreckovic [:milan]
Mentors:
Depends on:
Blocks: 790946
  Show dependency treegraph
 
Reported: 2012-07-20 09:13 PDT by Benoit Jacob [:bjacob] (mostly away)
Modified: 2012-09-13 06:36 PDT (History)
2 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
remove MOZ_EXT_texture_filter_anisotropic prefix (1.97 KB, patch)
2012-07-20 09:16 PDT, Benoit Jacob [:bjacob] (mostly away)
jgilbert: review+
Details | Diff | Splinter Review
Support EXT_texture_filter_anisotropic without prefix; warn on using the MOZ_ prefix (2.52 KB, patch)
2012-07-20 11:10 PDT, Benoit Jacob [:bjacob] (mostly away)
jgilbert: review+
Details | Diff | Splinter Review

Description Benoit Jacob [:bjacob] (mostly away) 2012-07-20 09:13:32 PDT
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) 2012-07-20 09:16:20 PDT
Created attachment 644364 [details] [diff] [review]
remove MOZ_EXT_texture_filter_anisotropic prefix
Comment 2 Vladimir Vukicevic [:vlad] [:vladv] 2012-07-20 09:18:18 PDT
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) 2012-07-20 09:37:39 PDT
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] 2012-07-20 09:40:34 PDT
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) 2012-07-20 10:04:43 PDT
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) 2012-07-20 11:02:36 PDT
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) 2012-07-20 11:10:49 PDT
Created attachment 644400 [details] [diff] [review]
Support EXT_texture_filter_anisotropic without prefix; warn on using the MOZ_ prefix
Comment 8 Benoit Jacob [:bjacob] (mostly away) 2012-07-25 11:15:26 PDT
http://hg.mozilla.org/integration/mozilla-inbound/rev/e5e8d176ac96
Comment 9 Ed Morley [:emorley] 2012-07-26 05:12:35 PDT
https://hg.mozilla.org/mozilla-central/rev/e5e8d176ac96

Note You need to log in before you can comment on or make changes to this bug.