[Public WebGL] (summarizing) Canvas.getContext error handling

Cedric Vivier [email protected]
Sun May 1 20:40:43 PDT 2011

On Sat, Apr 30, 2011 at 05:06, Glenn Maynard <[email protected]> wrote:
>> An application is notified that a context is not supported by returning
>> null.
>> The Canvas spec needs a minimal change equivalent of adding "or not
>> supported _right now_" to the statement above.
>> getContext spec does not have to even talk about the event at all :
> I think you're misunderstanding the problem.

I think we are just misunderstanding each other here ;-)

>The WebGL spec defines
> getContext as if it owns that API, but that API is part of and defined by
> the Canvas spec.  WebGL talks about things like "called for the first time"
> and "subsequent calls".  This is all precisely defined by HTML5.

I agree, we could remove or simplify this paragraph.

> If you ignore the normative spec for getContext, then you can indeed define
> getContext to do whatever you want, include dispatching an event, but that's
> not a good way to spec an API that makes use of another API.

The minor change necessary in the Canvas Spec is the addition of "or
null if the context could not be created" at step 6 :

"6. Return a new object for contextId or null if the context could not
be created, as defined by the specification given for contextId's
entry in the WHATWG Wiki CanvasContexts page."

There, this would be sufficient to keep both specs in line, isn't it?
[action item]

The part "as defined by the specification given for contextId" gives
us the leeway for any kind of WebGL-specific event dispatching
(whether it is for *diagnostics* _or for asynchronous context
This does not break the semantics or interface of getContext as an
exception would do (NB: getContext IDL does not have a "throw
DOMException" declaration).
As Benoit summarized, this is the path of least resistance and the
least breaking change.

> I disagree with each these.  If throwing an exception causes problems with
> debuggers, the debuggers need improvement.

Do you imply that moreover changing the Canvas spec and interface we'd
also need to change every debugger out there? ;-)

> the problem is that I don't thing *either* way can
> be specced properly without some help from HTML5's getContext spec.

Yes, we are aware of this. Hence why we are discussing the two
possible options with regards to the getContext spec :
Option 1 - add possibility or returning null at step 6 - doesn't break
current semantics/interface, shouldn't be much trouble to get this
upstream hopefully.
Option 2 - add possibility of throwing an exception - breaks current
semantics/interface, you attempted to push this upstream already and
it was not a welcome change.


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

More information about the public_webgl mailing list