On Thu, Nov 3, 2011 at 4:33 PM, Doug Sherk
<dsherk@mozilla.com> wrote:
I understand your concerns but I'm unclear as to whether you're
arguing that this extension should be vendor-specific to begin with
or not (i.e. WEBKIT_lose_context vs. WEBGL_EXT_lose_context for
example). If you believe it should be specific to each vendor, could
you explain why?
The extension probably should not be vendor-specific, that's not the issue. If you would like to ship a version of this extension it should use either a cross-platform prefix or a vendor-specific one specific to you, not to any other vendor. WEBGL_EXT_ or MOZ_ are fine things for Mozilla to ship, WEBKIT_ is not.
- James
Regards,
--
Doug
On 11/3/11 4:31 PM, James Robinson wrote:
On Thu, Nov 3, 2011 at 4:25 PM, Doug
Sherk
<dsherk@mozilla.com>
wrote:
The purpose of this
wasn't to steal the WebKit name or anything but to make it
easy to for developers to just use one extension name
instead of having fallbacks for each vendor. We went ahead
with WEBKIT_lose_context originally because the Khronos
conformance suite uses that specific name for all of its
tests. We're already in the process of moving to
MOZ_lose_context, but hopefully the name will be changed so
that this isn't something vendor-specific. Thanks for
understanding.
That's a very bad precedent to set. Vendor prefixes across
the web are for that vendor, not others. Would you add
support for -ms-interpolation-mode or
window.webkitRequestAnimationFrame in mozilla?
Do not do it.
- James
Regards,
--
Doug
On 11/3/11 4:20 PM, James Robinson wrote:
On Thu, Nov 3, 2011 at 12:56
PM, Benoit Jacob
<bjacob@mozilla.com>
wrote:
I would like this to be discussed in the next
conference call: are there any objections to
renaming/cloning WEBKIT_lose_context as
WEBGL_EXT_lose_context ?
It now seems that we're going to keep the
WEBKIT_lose_context name in the interim.
Mozilla should not ship anything with a WEBKIT
prefix. If you want to ship something with a
vendor-specific prefix use your own vendor name,
not someone else's. That way lies utter madness.
- James
Benoit
On 01/11/11 10:18 PM, Mark Callow wrote:
For the other
APIs the convention is to use EXT for
multi-vendor but not
Khronos ratified extensions. That would seem
to be appropriate here too.
It is nuts to have different names for the
same extension in different
browsers.
So the name of the extension would be
EXT_lose_context. The name string
for enabling it would be
WEBGL_EXT_lose_context as extensions always
start with the API name.
Regards
-Mark
On 02/11/2011 02:51, Benoit Jacob wrote:
On 01/11/11 01:41 PM, Adrienne Walker
wrote:
El día 31
de octubre de 2011 14:53, Benoit
Jacob<bjacob@mozilla.com>
escribió:
In the case of WEBKIT_lose_context,
since it is so simple and useful
for all
browsers, I would really like it to
become WEBGL_lose_context. Does
anybody
object to that and what steps need to
be taken to make that happen?
There was some previous discussion about
this here:
http://www.khronos.org/webgl/public-mailing-list/archives/1012/threads.html#00092
At the time, there were reservations
about adding the WEBGL tag
without more general approval or
ratification from Khronos.
Thanks, I didn't remember this
conversation. Since it seems to have
been such a large debate, for now we will
just rename it to
MOZ_lose_context on our side until
consensus for WEBGL_lose_context
happens.
Can I go ahead and add MOZ_lose_context to
the registry?
I disagree with the arguments that
WEBGL_lose_context is not needed as
it could be implemented in pure
_javascript_. A big focus at the moment
is to get Web developers to care about
contextlost/contextrestored
events. It would help if we could just
point them to a
WEBGL_lose_context extension to test their
app's behavior in all
supporting browsers, rather than having to
use a shim for all WebGL
entry points.
Cheers,
Benoit
-enne
-----------------------------------------------------------
You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org
with
the following command in the body of your
email:
unsubscribe public_webgl
-----------------------------------------------------------
-----------------------------------------------------------
You are currently subscribed to
public_webgl@khronos.org.
To unsubscribe, send an email to
majordomo@khronos.org
with
the following command in the body of your
email:
unsubscribe public_webgl
-----------------------------------------------------------