- From: Maciej Stachowiak <mjs@apple.com>
- Date: Wed, 15 Mar 2006 13:56:18 -0800
- To: Jim Ley <jim@jibbering.com>
- Cc: public-webapi@w3.org
On Mar 15, 2006, at 1:31 PM, Jim Ley wrote: > > "Maciej Stachowiak" <mjs@apple.com> >> That's not backwards compatibility, backwards compat for a spec >> means authoring to the lower version still works in the higher >> version. No spec attempts to guarantee forward compatibility >> except possibly via fallback mechanisms that cause future >> features to be ignored. > > I disagree, all well authored specs, particular in situations such > as web api's where there is no way to tell what version of an API > is in use (hasFeature is meaningless, and even if it wasn't there's > no way yo're doing something useful if you say hasFeature 2.0 > returns false when 3.0 returns true. If you feel strongly that it is important to distinguish when order of even dispatch is guaranteed, we could add a property to test for it. But if you think it doesn't have important use cases, then I don't see why it is important to tell when it is in effect. >> So I don't think this is a valid concern. > > It's a a very big concern for content authors, we can't know what > environment we're running in, that means we will always be doing > the 2 behaviour, this makes the 3 behaviour irrelevant. As far as I am concerned, it would be just fine for content authors to write their content as if order of event dispatch were undefined, but for UAs to still do dispatch in a consistent order for better interoperability in case the author accidentally depends on order. Keep in mind that the spec is not just a contract between content authors and impementors, but also a contract between different implementations. If it makes a promise that you, as a content author, would rather not rely on, then you are free to ignore it and I do not see the harm done. >> I disagree. Leaving the ordering unspecified will likely result in >> content accidentally depending on the ordering of whatever UA it >> is tested in. > > I think you need to point to large amounts of code that does this, > ie it's a genuine problem, I do not believe it is. I wouldn't know how to tell if there's code out there that could depend on order of event dispatch. My experience with large systems is that it's hard to avoid dependencies like this creeping in. > >>> You can in some current implementations, >> >> Which current implementations will let you have separate <foo >> onclick=""> and foo.onclick handlers and fire both? > > Mozilla, see the code earlier in the thread. I tried the following test case in Mozilla Firefox 1.5.0.1 based on your example and only 3 is alerted: <html> <body> <script> document.body.onclick = function() { alert(2) } document.body.setAttribute('onclick','alert(3)'); </script> </body> </html> Regards, Maciej
Received on Wednesday, 15 March 2006 21:56:35 UTC