- From: Christian Parpart <cparpart@surakware.net>
- Date: Wed, 30 Jul 2003 00:14:53 +0200
- To: Philippe Le Hegaret <plh@w3.org>
- Cc: www-dom@w3.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 24 July 2003 8:28 pm, Philippe Le Hegaret wrote: > On Mon, 2003-07-21 at 10:21, Christian Parpart wrote: > > 1. Event.preventDefault() vs. preventImmediateDefault() > > > > Where exactly is the difference between Event.preventDefault() > > and Event.preventImmediateDefault()? Sorry, I did not understand > > it - and even why :( some examples would really help, probbably :o) > > The Event interface never had a preventImmediateDefault. You should > compare stopImmediatePropagation and stopPropagation. Let me know if > you're still having problems understanding the diferences. I do believe > it is clear enough in the current draft. Yeah, sorry, I meant stop[Intermediate]Propagation. It must have been very very late while writing this mail ;) Well, okay, I got some private help by a nearly native speaker ;) *NOW* I believe to understand.... > The draft is at > http://www.w3.org/TR/2003/WD-DOM-Level-3-Events-20030331/ > > > 3. DISPATCH_REQUEST_ERR > > > > I do not understand why and when this can happen. the spec says "If the > > Event object is already dispatched in the tree." > > While this may happen in the dispatchEvent method I really have no case > > for this to be thown. Could you give me an example what exactly is meant > > by the spec? > > An event listener could certainly try to dispatch the event object it > just received: > function myListener(e) > { > myOtherTarget.dispatchEvent(e); > } > > While the event model is reentrant (see section 1.2.2.5), the DOM Event > API does not allow the same event object to dispatch in the tree twice > at the same time. So the event listener above will always raise a > DISPATCH_REQUEST_ERR exception. Ah, thanks, now I know what's meant ;) If really someone wanna redispatch an event he shall clone this event and dispatch the clone instead of of above case. function ilovejs(e) { myOtherTarget.dispatchEvent(e.clone()); } Yet another thing: Event.eventPhase() vs. Event.type() I feel really not very happy about both Event properties. I'd either propose to name both as: Event.eventPhase() and Event.eventType() or Event.phase() and Event.type(). But having: Event.eventPhase() and Event.type() looks very inconsistent to me :( > > 5. XPath result sets > > > > Why the hell did you change the return type of all all the query > > methods from XPathResult to DOMObject? > > XPath 2.0 is the reason. The idea is to be able to return XPathResult2 > (for XPath 2.0 result objects). Since no implementation will provide XPath 1.0 *and* XPath 2.0 inclusivily. I'd propose to keep that name XPathResult and just extend/modify this interface. I really has no need to be backward compatible since we're talking about a big version move (vom 1.0 to 2.0 ;) > > Well, this may be straight forward compatible, but I always need > > to dynamic_casrt here to test whether the result is *really* of > > type XPathResult. This is really everything but performance friendly :( > > Noted. Not sure if we will do something about it but this is exactly the > kind of comments we'd like to hear during the Candidate Recommendation > period. I suggest to provide generic XPathResult interface that provides some kind of read-only property telling me what kind of result I have. You may compare this to Node.nodeType() that can be implemented very fast by just returning a member variable inline (in case of C++). Greets, Christian Parpart. p.s.: now it looks like I've Events module completed before Core... *heh* - -- 21:16:26 up 70 days, 12:22, 0 users, load average: 0.02, 0.03, 0.05 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/JvHePpa2GmDVhK0RAnSpAJ0ROOIZQe4EX7ummAxORf83nRzt2wCfTx7W 0M2yPAWK7eTQ/vPdstVFpSg= =tgZ9 -----END PGP SIGNATURE-----
Received on Tuesday, 29 July 2003 18:10:38 UTC