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

[Bug 12458] Interface objects should be Functions

From: <bugzilla@jessica.w3.org>
Date: Thu, 30 Jun 2011 19:22:27 +0000
To: public-script-coord@w3.org
Message-Id: <E1QcMol-0007Ar-Ad@jessica.w3.org>

Garrett <dhtmlkitchen@gmail.com> changed:

           What    |Removed                     |Added
                 CC|                            |dhtmlkitchen@gmail.com

--- Comment #14 from Garrett <dhtmlkitchen@gmail.com> 2011-06-30 19:22:25 UTC ---
In response to Comment 3 Simon Pieters 2011-04-11, there are compatibility

Changing behavior of existing methods and properties generally adds complexity.
 That complexity is augmented by variance in browsers, versions, and existing

The CSSOM/offsetTop changes comes to mind (see long threads on www-style

The problem with changing behavior that it adds complexity to web page authors.
It makes feature detection much harder because there are multiple cases to deal

1) Browser has existing native Event interface object: (typeof Event ==
2) Browser does not have native Event interface object:
(typeof Event == "undefined").
3) Browser has new native Event interface object: (typeof Event == "function"
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).
b) MooTools:
| var Event = new Type(... (typeof Event == "function" (always)).

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.

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

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.

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 Thursday, 30 June 2011 19:22:28 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:37:44 UTC