W3C home > Mailing lists > Public > public-script-coord@w3.org > July to September 2011

[Bug 12458] Interface objects should be Functions

From: <bugzilla@jessica.w3.org>
Date: Fri, 01 Jul 2011 01:43:31 +0000
To: public-script-coord@w3.org
Message-Id: <E1QcSlX-0005Q0-Gr@jessica.w3.org>

--- Comment #15 from Cameron McCormack <cam@mcc.id.au> 2011-07-01 01:43:30 UTC ---
(In reply to comment #14)
> It makes feature detection much harder because there are multiple cases to deal
> with:
> 1) Browser has existing native Event interface object: (typeof Event ==
> "object")
> 2) Browser does not have native Event interface object:
> (typeof Event == "undefined").
> 3) Browser has new native Event interface object: (typeof Event == "function"
> (new)).

Is it so that you can tell whether you can construct an Event object with new
or not?  You can do that with:

  var canConstructEvent = false;
  try {
    new Event("a");
    canConstructEvent = true;
  } catch (e) {

> 4) App is using a framework that adds/replaces global `Event`
> a) Prototype.js 
> | if (!window.Event) var Event = { }; (
>   i. Older Event interface obj (see 1).
>   ii. No Event interface obj: (creates a new user-defined Object object (typeof
> Event == "object") (different from (2)).
>   iii.  New Event interface obj: (see 3).

I'm not sure what the point of 4a is here.  (I checked out the source to
Prototype.js and couldn't find this code.)

> b) MooTools:
> | var Event = new Type(... (typeof Event == "function" (always)).

I'm not sure what you're saying with this one.  Do you need to be able to
distinguish between a native Event interface object and the one MooTools
creates?  If so, doing `typeof Event == "object"` doesn't seem to be the best
way to do this.

> As the Event interface evolves, the new functionality must also be feature
> tested. This situation of feature testing the global Event constructor becomes
> more difficult.

I don't understand why this becomes more difficult.

> For a copy'n'paste coder who tests in three browsers, a changed Event object
> will probably lead to compatibility bugs.

It really depends on whether they're copying-and-pasting code that checks
`typeof Something == "object"`.  I find a few but not many instances of this


> Now, OTOH, a *new* method can avoid dealing with legacy code issues:
> | if(window.Event && typeof window.Event.createInitedEvent == "function") {
> |   Event.createInitedEvent(type, optionObj)
> | }
> It should be a safe bet to assume that if `createInitedEvent` is present, it's
> not something that MooTools added. This avoids compatibility issues.
> Copy'n'pasters can drop that on into a web page and browser vendors should not
> see "TypeError Event is not a constructor", etc.

This sounds like an issue for the DOM Core/Events specs, not Web IDL.

Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
Received on Friday, 1 July 2011 01:43:32 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:03 UTC