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

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
constraints.

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


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

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