[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Public WebGL] WebGL extensions vendor prefixes again


With EXT_texture_filter_anisotropic now implementable prefix-free, this topic has come up again, but in a more concrete form than before.

 - WebGL uses "CSS-style" vendor prefixes i.e. each vendor has a monopoly on their own vendor prefix.
 - This is unlike OpenGL where vendors are allowed to implement each other's vendor-prefixed extensions.

The problem with the current WebGL situation is that we are stuck in this dilemma:

 - On the one hand we want to drop support for prefixed versions of EXT_texture_filter_anisotropic ASAP to avoid them getting too entrenched. Otherwise we may have to keep supporting the vendor-prefixed strings forever, which is bad for us already, so think about how bad it would be for a future prospective WebGL browser vendor --- they would be locked out from being able to render these Web pages.

 - On the other hand we want to avoid breaking existing Web pages which means that we're not comfortable with just dropping support for the vendor-prefixed string overnight.

The compromise we've chosen for EXT_texture_filter_anisotropic is to have Firefox 17 support both the prefixed and unprefixed versions and warn on the prefixed one, and then drop the prefixed one in Firefox 18 which will come 6 weeks later --- about 6 months from now.

The question is what can we do to avoid prefix hell next time?

Idea #1 (most conservative, incremental improvement): When an extension becomes implementable prefix-less, if all the variants of the spec (the prefix-less spec and the various prefixed specs) are identical, as is the case with EXT_texture_filter_anisotropic, then at that time it should become legal to implement each other's vendor prefix for this extension.

Idea #2: When discussing a new extension proposal, if vendors agree that it's not a contentious topic and that they will be happy with whatever other vendors come up with, then we could agree to go prefix-less right away, so the draft proposal could be implementable without a prefix. Indeed, most WebGL extensions so far have been non-contentious.

Idea #3 (variant of #2): We could instead decide to allow vendors to implement each others' vendor prefixed extensions already during draft stage. The obvious objection is that in this case, prefixes are useless and we may want to go for #2 instead, but one could argue that prefixes still serve a purpose. In particular, this would help in the case where there are two competing approaches. Vendors implementing another vendor's prefix should make every attempt to adhere to the prefixed spec; otherwise, if they want to implement a different spec, they should make their own proposal and have their own vendor prefix.

Idea #4 (the least conservative; my personal preference): just switch wholesale to the OpenGL way of vendor prefixes i.e. allow vendors to implement each other's vendor prefixed extensions. It would remain a requirement (like for OpenGL) to adhere to the spec --- vendors wanting to depart from a prefixed spec would have to use their own prefix instead. This seems to be working already quite well for OpenGL and the fact that WebGL has a tighter extension process where a proposal must have approval from this Working Group before even prefixed implementations can start to exist in the wild, suggests to me that this would work well for WebGL too.



You are currently subscribed to [email protected]
To unsubscribe, send an email to [email protected] with
the following command in the body of your email:
unsubscribe public_webgl