DOM event handlers
rg...@iinet.net.au
says for all the entries:
'Returns the event handling code for the <type> event'
where <type> is onblur, onclick, etc.
But that is not correct. Accessing the property will return a reference to the
value of the property, which, if set, is a function object.
The introductory text is very good, it even says that the values aren't strings.
I think this can be fixed with a few minor changes to the current text, plus
all the entries should be changed to:
'Returns a reference to the event handler for the <type> event'
By way of explaination:
If the parameter passed to 'alert' is a function object, then its toString()
method is called before displaying it. This causes the code to be shown - the
value of the onclick attribute is still a function object, just that using
'alert' makes the code be displayed.
For example if you have:
<button onclick="alert(this.onclick)">click me!</button>
Then clicking on the button will show:
function onclick(event) {
alert(this.onclick);
}
However, clicking on this button:
<button onclick="alert(typeof this.onclick)">click me!</button>
shows:
function
i.e. the onclick property is a function, not some code.
Hope I didn't just bore you all silly...
Nickolay Ponomarev
> Hope I didn't just bore you all silly...
This is all correct and you could just have gone ahead and fixed this,
but I think we should instead document the events themselves and not
the on* properties.
All the on* properties/attributes are used in a similar way - you can
set a handler function to the property, and you can get it back by
reading the property. This information is currently duplicated on all
the DOM:element.on* pages. The meaning of the correspondent event is
usually explained in the Notes section, in a sentence or two.
There are two downsides to this approach. First is the already
mentioned duplication. Second is the fact that there is no useful and
easy to find (and link to) documentation for people using interfaces
defined in DOM Events (e.g. authors of extension or advanced web
apps).
I suggest that we move the all (?) DOM:element.on* pages to
DOM:Events:* or maybe simply DOM:* (e.g. [[DOM:blur]]), strip the
pages from the currently useless IMO summary/syntax/example sections,
replacing them with a section that states in a concise way that you
can set the event handler in three different ways and also links to a
page with the detailed explanation of event handlers (something like
what is described in [1]).
The DOM:element page could then just say that there are a number of
events that have the correspondent on* properties, then list those
properties/events. I would replace the currently repetitive
descriptions with descriptions of the events themselves.
[1] http://mail.mozilla.org/pipermail/devmo-general/2005-December/000600.html
Nickolay
Christian Biesinger
> If the parameter passed to 'alert' is a function object, then its toString()
> method is called before displaying it.
That happens for all non-string objects passed to alert...
rg...@iinet.net.au
> On 3/15/06, rg...@iinet.net.au <rg...@iinet.net.au> wrote:
> > Hope I didn't just bore you all silly...
>
> This is all correct and you could just have gone ahead and fixed this,
> but I think we should instead document the events themselves and not
> the on* properties.
I think it's better to discuss it first and get a single, good result.
> All the on* properties/attributes are used in a similar way - you can
> set a handler function to the property, and you can get it back by
> reading the property. This information is currently duplicated on all
> the DOM:element.on* pages. The meaning of the correspondent event is
> usually explained in the Notes section, in a sentence or two.
The intrinsic events should be on a single page, say DOM:element:intrinsicevents
that shows how to add and remove events and the consequences of various methods
of doing that. It could just be on the element page, but that would make it too
hard to link to.
Each intrinsic event could also list the elements it applies to - e.g. blur
applies to select, input, textarea and anchor elements.
Each element interface page (e.g. HTMLSelectElement, if there was one) can then
list the methods that apply to that interface (for select, blur and focus).
Those that relate to intrinsic events can link to the
DOM:element:intrinsicevents page.
[...]
> I suggest that we move the all (?) DOM:element.on* pages to
> DOM:Events:* or maybe simply DOM:* (e.g. [[DOM:blur]]),
I'd suggest something under DOM:element. They are listed in the DOM HTML
specification, they don't belong to the Events spec.
Nickolay Ponomarev
On 3/17/06, rg...@iinet.net.au <rg...@iinet.net.au> wrote:
> > All the on* properties/attributes are used in a similar way - you can
> > set a handler function to the property, and you can get it back by
> > reading the property. This information is currently duplicated on all
> > the DOM:element.on* pages. The meaning of the correspondent event is
> > usually explained in the Notes section, in a sentence or two.
>
> The intrinsic events should be on a single page, say DOM:element:intrinsicevents
> that shows how to add and remove events and the consequences of various methods
> of doing that. It could just be on the element page, but that would make it too
> hard to link to.
>
> Each intrinsic event could also list the elements it applies to - e.g. blur
> applies to select, input, textarea and anchor elements.
>
Sounds fine, although I don't think we should limit ourselves to
intrinsic events.
Also the page doesn't have to be under DOM:element. We try to use
shorter names when it doesn't cause confusion.
> > I suggest that we move the all (?) DOM:element.on* pages to
> > DOM:Events:* or maybe simply DOM:* (e.g. [[DOM:blur]]),
>
> I'd suggest something under DOM:element. They are listed in the DOM HTML
> specification, they don't belong to the Events spec.
My point was that we document the *events* (as opposed to the on*
properties). There are HTML-specific events, XUL-specific events,
events defined in the Events spec, etc. I think we should either put
them all on a single page, on DOM:<event name> pages, or something
like DOM:Events:<event name>. I'm leaning towards one of the first two
variants.
Maybe given how little information we have now, put all events on a
single page and create the pages with detailed descriptions/notes
later?
Nickolay