Re: Detecting and Creating Events

On Mon, Aug 24, 2009 at 2:54 AM, Stewart
Brodie<stewart.brodie@antplc.com> wrote:
> Garrett Smith <dhtmlkitchen@gmail.com> wrote:
>
>> On Thu, Aug 20, 2009 at 4:32 AM, Stewart
>> Brodie<stewart.brodie@antplc.com> wrote:
>> > Garrett Smith <dhtmlkitchen@gmail.com> wrote:
>> >
>> > > The inability to easily and accurately detect events is a problem.
>> > > Programs want to know if an event is implemented at runtime. If it is,
>> > > then the feature can be used. If not, it a fallback stratety is in
>> > > order. Many new event types are being created and implemented. How can
>> > > a program feature-test to see if they are implemented?
>> >
>> > DocumentEvent.canDispatch() would seem to fit the bill, although it's
>> > not clear exactly what criteria this method is supposed to base its
>> > answer on right now.
>>
>> I see. It wouldn't really "fit the bill", unless it did, but since we
>> don't know if it does, it must seem so.
>>
>>
>> > You could suggest a clarification for the text and then you don't need
>> > to add all those new methods.
>>
>> No, that "canDispatch" sounds like almost as bad an idea as hasFeature. I
>> learned not to trust crap like that quite good many years ago.
>
> And yet you want to introduce another feature-detection mechanism that
> doesn't work properly (too many false negatives, as you point out)?

You aren't being direct or specific.

The problem is that a program needs to know if an event will fire.

>
>
>> >> There should be a simple way to create and fire an event.
>> >>
>> >> interface DocumentEvent {
>> >>   Event createInitedEvent(in domstring type, in Object options)
>> >>   raises(dom::DOMException);
>> >> }
>> >
>> >> In createInitedEvent, the type of event created is determined by the
>> >> string arg /type/, which is a prefixed with a DOM Interface (as a
>> >> string) followed by ".", followed by the event type. The event is
>> >> inited with the /options/. This is a "map" of options that the event
>> >> has, such as - offsetX - , - pageY - , etc.
>> >
>> > I don't like this interface at all, for several reasons:
>> >
>> > I think it unwise to add it to DocumentEvent - what about events that
>> > are nothing to do with documents?
>>
>> All "createXXX" methods are based off document, e.g. "createTextNode",
>> "createEvent".
>>
>> I'm not proposing to change that.
>
> OK.
>
>> > I don't like Object being passed to a DOM method. The moment you permit
>> > arbitrary JS objects in a DOM API, the implementation of that method has
>> > to deal with so many more problems (e.g. dealing with infinities, NaNs,
>> > other objects).
>> >
>>
>> Infinity and NaN are numbers, not objects.
>
> I wasn't clear.  These arbitrary objects that you are intending to pass in
> to this method may have any number of properties, the types of these
> properties may be infinities, NaNs, numbers, other objects, strings, etc.
>

Again, inifinity, NaN, and number are all "number" type; they don't
fall in the category of "object" or "other objects".


> Thus DOM code now has to be able to deal with these types,

What "DOM code"?

> it does not because, to use my examples, infinities and NaNs are not
> permitted in a DOM interface.

So? If I pass - 0 - to - initMouseEvent - as the - canBubbleArg - ,
isn't the program in the same position?

A)
var bubbles = 0; // Programmer error: should be boolean.
obj.initMouseEvent("click", bubbles , false [,etc...]);

B)
var bubbles = 0; // Programmer error: should be boolean.
obj.dispatchInitedEvent("MouseEvent", "click", {
  canBubbleArg : bubbles ,
});

Same problem.  Doesn't matter how the value is passed. That "problem"
exists either way, so cannot be considered a valid reason for not
using an object of properties and favoring an ArgumentList.  More like
a red herring.

An implementation might handle that invalid value by throwing an
error, or it might want to use ECMAs ToBoolean. Or the program could
just not do that.


 In all the other cases I've noticed where
> arbitrary objects are passed to a DOM method, the object is only ever passed
> back to the scripting engine that created it and interpreted there.
>

I'm not seeing the point.

>
>> > There's nothing to stop you assigning additional properties to the Event
>> > object after you've initialised it.
>>
>> Yes, there are. It's called errors. Ever try to assing to modify a
>> host object? Try setting the pageX property in a few versions of
>> Firefox and see what happens.
>
> I'm not surprised.  I've found the DOM event support to be so inconsistent
> between Firefox, Opera & Webkit (and non-existent in IE), that I've long
> since given up trying to work out what they do and don't support so I can be
> interoperable.  Sadly, just implementing the standard DOM events
> specification makes you non-interoperable (due to the capturing listeners
> being called in the at-target phase bug in Firefox, at least, as was
> discussed here IIRC a few months ago)
>

That was reported five years ago.
https://bugzilla.mozilla.org/show_bug.cgi?id=235441

Opera 9.5+, 10b, Seamonkey, Safari 2, 3, 4, Chrome all fail with:
| Capture event listener fired on target element (should never happen).

This is getting a bit far from the point I was trying to make about
"don't modify host object" which came in response to your suggestion
of adding a pageX property manually.

>
>> Or try using some the libraries that modify host object prototype ,e.g.
>> Mootools or Prototype.js, and see how they fall apart cross-frame. I see
>> also Dojo still modifies the pageX property of events, in _fixEvent.
>> Modifying host objects is error-prone.
>
> All those libraries and other well-known ones, like jQuery, tend to rely on
> unreliable feature detection and built-in knowledge of different browsers
> and even bugs.
>

My point was that modifying host objects, even if a very
common-practice, is error prone.

>
>> >> DOM 2 Events provides "createEvent(type)", but then required an
>> >> additional step initEvent or initMouseEvent. Method initMouseEvent
>> >> takes 15 arguments, none of them are memorable. It is painful to use.
>> >
>> > Honestly, how often does scripting wish to simulate UIEvents,
>> > MouseEvents, KeyboardEvents, MutationEvents or MutationNameEvents?  The
>> > only use case I can think of is a test harness that's trying to drive an
>> > application under test.
>>
>> A test framework is one case.
>>
>> Another case is when a program needs to know if an event is supported,
>> and how it is implemented (what happens when it fires).
>
> What does it mean for an event to be "supported" anyway?    Does it mean
> that the implementation may generate the event itself?

A cross-browser program needs to know beforehand if an event will
fire. If it is know that the event won't fire, the program can use a
different strategy. An event cannot be expected to be implemented in
all browsers. A particular event may be known to be not implemented in
less-recent browsers. For example, "domfocusin". How do you detect
that? How can a program know if a "submit" event will bubble?

[...]

Garrett

Received on Monday, 24 August 2009 17:49:06 UTC