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

Re: [Public WebGL] Should WebGLContextEvent have a constructor?

Yes, I think it's appropriate to update the definition of this event
to track that of other events in the HTML spec.

Would you mind filing a bug on http://www.khronos.org/bugzilla/ about
this? Product WebGL, Component Specification. If this is too much work
let me know and I'll do it.

A snapshot of the next version of the WebGL spec is underway and this
might need to wait until after that's done. However this change
shouldn't affect any applications since they shouldn't need to
instantiate these events themselves.


On Mon, Nov 7, 2011 at 2:30 PM, Dominic Cooney <dominicc@chromium.org> wrote:
> I notice that many recent drafts of contemporary specs (eg DOM4, HTML5,
> Workers, WebSockets, etc.) specify events as having constructors, and not
> init*Event methods. For example, DOM4 specifies CustomEvent this way:
> <http://www.w3.org/TR/domcore/#interface-customevent>
> [Constructor(DOMString type, optional CustomEventInit eventInitDict)]
> interface CustomEvent : Event {
>   readonly attribute any detail;
> };
> dictionary CustomEventInit : EventInit {
>   any detail;
> }
> Would it be appropriate to change the definition of WebGLContextEvent from
> this:
> interface WebGLContextEvent : Event {
>   readonly attribute DOMString statusMessage;
>   void initWebGLContextEvent(DOMString typeArg,
>     boolean canBubbleArg,
>     boolean cancelableArg,
>     DOMString statusMessageArg);
> };
> To this:
> [Constructor(DOMString type, optional WebGLContextEventInit eventInitDict)]
> interface WebGLContextEvent : Event {
>   readonly attribute DOMString statusMessage;
> };
> dictionary WebGLContextEventInit : EventInit {
>   DOMString statusMessage;
> };
> Dominic

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