Re: Enumeration of EventListeners in DOM Level 3 Events

Richard Schwerdtfeger wrote:

>Ray,
>
>One of the problems you and I are both dealing with is the state of things
>(almost 2 years ago) with what they are now. Talking about implementing a
>semantic model 2 years ago was not realistic. Yes its almost 2 years we
>talked about the issues. (January FTF)
>
Nothing that big has changed.  A simple concept of semantic events made 
just as much sense then or now.  It doesn't take all these fancy things 
you seem to imply.  The fancy stuff is for hackish scab type solutions. 
 Design semantically, and there is no problem.  For 80-20 coverage, it 
is hardly more than a new type of event and event object.  If it had 
been done two years ago, people would be using it soon and you would be 
recommending it today.

>maintain the hackish approach when you can move towards a simple >semantic
>design that will be easier for everyone.
>
>I am listening. I don't disagree that semantic events would be very useful.
>However, I believe that what you would like to impose on a script writer
>requires an immense amount of work and that web content, in general today,
>does not support it. Currently, there is no notion of a semantic event in
>JavaScript. JavaScript is very low level. Nobody is asking to "hack"
>anything. The problem is there has been a lot of push back to accept event
>activation of any form. It is a lot of work for the DOM working group.
>
You are asking that UI listeners be something other than what they are 
naturally -- semantically useful.   Listeners would have to be rewritten 
semantically to work the way you want to use them.  I much prefer the 
path of actually having official semantic events, even if very simple, 
rather than the huge hassle and disappointment of pretend that a UI 
event is semantic, when such pretense will break down if it is not, 
requiring code to be rewritten in any case but not honestly or sensibly 
according to the rules for the event types.

Javascript needs to have no concept of semantic events.  All you have to 
do is make a new type of event that IS reasonable to enumerate and 
activate by menu.  The first step would be a no-argument version that 
just carried a reasonably entry for a menu.  Javascript should not be 
aware of this type of thing at all.  Using these is much easier than 
adding a description to semantically-undescribable handlers of today.

Separating out actions in this way is not hard for some use cases. 
 Others might have to wait until more advanced semantic events were 
invoked, but these would likewise not be solvable by scabbing things 
onto UI listeners.

There was never significant push back to accept event activation.  That 
is why it has been there wide open since earliest level 2 -- before we 
talked to you 2 years ago -- precisely because most people can think of 
cases where it is useful.  Unlike listener enumeration, it is not a 
broken concept.

>>As I have said, the ability to ask about the presence of a specific type
>>
>of listener in the hierarchy of a particular node is something we could
>
>>discuss, but you have a lot of broken ideas in this writeup to overcome,
>>
>so don't blame us that you didn't do symantic events.  They are not that
>
>>hard.
>>
>
>I think we are talking about the same thing. Unfortunately, most event
>usage today does not support semantic information and we have to deal with
>lots of legacy script on the web. Doing semantic events will not cover the
>bulk of what is out there is built on a non-semantic infrastucture in which
>case the use of descriptions is very helpful. The legacy information we
>have today is onblur, onfocus, onactivate, onclick, etc. Below this we have
>an attached function (whatever it is).
>
The descriptions are useful if you want lies or if your events are 
already artificially semantic (ignoring parameters and hardware state, 
mapped to high-level functions).  Otherwise, they are not and trying to 
use them that way only breeds frustration.

Why try to scab semantic information on top of existing handlers which 
typically cannot properly be described that way.  It is far easier to 
separate out specific semantic actions than to try to ascribe semantics 
to actions which are non-semantic because they have to fiddle with the 
UI and state and codes.

Ray Whitmer
rayw@netscape.com