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>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12458

--- 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
with:

http://www.google.com/codesearch#search/&q=typeof%5Cs*%5C%28?%5Cs*%5BA-Z%5D%5BA-Za-z%5D%2B%5Cs*%5C%29?%5Cs*%5B!=%5D==?%5Cs*.object%20lang:%5Ejavascript$%20case:yes&sq=&type=cs

> 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.3.1 : Wednesday, 8 May 2013 19:30:04 UTC