- From: Anne van Kesteren <annevk@opera.com>
- Date: Sun, 14 May 2006 12:41:16 +0200
- To: "Jim Ley" <jim@jibbering.com>
- Cc: "Web APIs WG (public)" <public-webapi@w3.org>
On Thu, 06 Apr 2006 11:51:17 +0200, Jim Ley <jim@jibbering.com> wrote: >>> I don't see why responseText MUST be null other than in readyState 3 >>> or 4, why not undefined (e.g. if the firing of the 2 is delayed for >>> some reason then data could be available) Equally MUST on 3 is >>> incompatible with existing implementations. >> >> It's never null. If the firing of the 2 is delayed, isn't that just a >> bug? > > No, we're not mandating that events fire in realtime - we can't as ES is > single threaded etc. Another way of saying is that until you fire the event the attribute MUST be the empty string... >> The "MUST on 3" is incompatible with existing implementations in what >> way? > > MS's XHR implementation throws an error on 3. I'm in favor of leaving the specification as is and considering what IE does at the moment as a bug. >>> alert( ) isn't defined anywhere, traditionally print has been used as >>> a dummy function in ES code. >> >> Any pointers of its use? > > The ES spec, just changing alert to print... Used a print() function instead. >> by data.xmlEncoding, if specified and supported, or UTF-8 otherwise >> >> Makes some sense to me... > > I still don't see the point of the restriction at all, and inputEncoding > would be a better option than xmlEncoding - if we're assuming the > server knows the best format for a document serialisation, but I don't > see the point of requiring such behaviour. See ISSUE-83. -- Anne van Kesteren <http://annevankesteren.nl/> <http://www.opera.com/>
Received on Sunday, 14 May 2006 10:41:35 UTC