W3C home > Mailing lists > Public > whatwg@whatwg.org > June 2007

[whatwg] Scripting Tweaks

From: Ian Hickson <ian@hixie.ch>
Date: Tue, 5 Jun 2007 06:45:25 +0000 (UTC)
Message-ID: <Pine.LNX.4.64.0706050639090.13385@dhalsim.dreamhost.com>
On Mon, 4 Jun 2007, Maciej Stachowiak wrote:
> > 
> > I can if you want, but I don't really see it as a feature that would 
> > be expected in DOM3 Events. DOM Events defines the event 
> > infrastructure; it doesn't define when and how each event is actually 
> > fired. The firing of the events in HTML is very closely tied to the 
> > rest of the HTML processing model.
> 
> It also defines the names of events

Just referring to the event defines the name, so that's a non-issue.


> their associated IDL interfaces, 
> whether they bubble, whether they are cancellable, and so forth. 

That is independent of the name, and determined when you fire the event. 
There are some events that sometimes bubble and sometimes don't, for 
instance. In fact I would say that it's up to the spec that fires the 
event to define whether they bubble, have default actions, etc. 


> DOM 3 Events defines this for the "load" event for instance.

I would argue that it shouldn't.


> It seems to me that "load" and "DOMContentLoaded" can both be defined in 
> ways that are independent of the specific markup language, and are 
> equally deserving of being in DOM 3 Events itself. Certainly in a user 
> agent that supports multiple markup languages, you'd want 
> DOMContentLoaded to be dispatched for all of them under the same 
> conditions.

I guess it makes sense to have a non-normative (because there's nothing 
to be normative about) repository somewhere that lists event names and 
which specs are using them, so that specs can remain consistent on the 
matter. But I don't think DOM3 Events need be it; it's a lot of work. For 
example, all the HTMLMediaElement events would need to be added to the 
list.


> Finally, the reason it was left out in the first place was largely due 
> to presumed lack of use cases, not because it was believed to require 
> language-specific processing rules. And that argument was accepted 
> largely due to your support for it. So it would be good to at least 
> present the new info.

I really don't think that my input had much influence on the matter. This 
is the sum total of what I said about it:

| All in all I'm in agreement with the sentiment on this thread that 
| DOMContentLoaded's use cases are unconvincing.

...and that still stands. However, a lot of people have indicated that 
there _are_ use cases, and that they really want support for this. Since 
browsers support it and aren't going to _remove_ support for it, we have 
to specify it, and hence it gets added to the spec.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Monday, 4 June 2007 23:45:25 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:58:56 UTC