Domita doesn't attempt to hide browser differences

[GoogleCodeExporter]

For example

    TameEvent.prototype.getButton = function () {
      var e = this.event___;
      return e.button && Number(e.button);
    };

but the meaning of the Event.button property differs between browsers:
http://www.quirksmode.org/dom/w3c_events.html#miscprop

There are probably many cases like this.

Original issue reported on code.google.com by davidsar...@googlemail.com on 12 Jun 2008 at 11:17

[GoogleCodeExporter]

Also the Event.target property is called Event.srcElement in IE, but srcElement 
is
not made available through TamedEvent, so the property is not accessible at all 
in IE.

Original comment by tyler.cl...@gmail.com on 13 Jun 2008 at 12:09

[GoogleCodeExporter]

I don't think we should make any attempt to hide browser differences.

Original comment by mikesamuel@gmail.com on 29 Aug 2008 at 3:35

[GoogleCodeExporter]

Ihab and Tobie Langel suggested the following approach, which I agree with:

<http://groups.google.com/group/google-caja-discuss/browse_thread/thread/d445627
60ffad931>

Other than that, Domita is missing a large number of features which
currently makes porting libs such as Proto/jQuery/etc totally
impractical. In my opinion, handling these issues on a case per case
basis is not a good option. Instead, I'd suggest the following:

* Domita implements the W3C specs as closely as possible and nothing more,
* it sits on a layer handling browser discrepancies (lovingly
codenamed BRIDAL by Ihab), which would be extracted from current
libraries and reused, in Prototype and possibly elsewhere.

This suggestion comes from the observations I've made and the
discussions I've had with framework developers, notably SproutCore,
Objective-J/Cappuccino and Coherent.

Currently all the main libraries do two things: 1) they handle
cross-browser issues and 2) they provide a DSL. This implies that all
libs go through the same tiresome and bug prone process of
cross-browser coding.

Instead, I'd suggest separating the two concerns. BRIDAL would handle
the browser abstraction and be aimed at framework developers or for
coding in  specific contexts (writing bookmarklets, for example). It
would be built for speed, low memory consumption, unobtrusiveness and
security and would be kept strictly to a self-contained object
exposing only an API of generics. Other libraries could just sit on
top of it.

Original comment by davidsar...@googlemail.com on 14 Sep 2008 at 10:37

[GoogleCodeExporter]

We now attempt to but fail.

It is not a goal to prevent a script from determining the platform its running 
on,
but bridal has been implemented and it is a goal to smooth over browser 
differences.

Original comment by mikesamuel@gmail.com on 25 Sep 2009 at 7:38

• Changed state: Fixed