Re: Progress Events normative text

On Sat, 30 May 2009 09:26:40 +0200, Charles McCathieNevile <chaals@opera.com> wrote:
> On Wed, 22 Apr 2009 16:57:41 +0200, Anne van Kesteren <annevk@opera.com>  
> wrote:
>> I can see some value in this specification giving advice as to what the  
>> names of the events should be and what order they should be dispatched  
>> in, but that should only be advice to specification authors, not  
>> requirements on user agents. The requirements on user agents should be  
>> elsewhere.
>
> This is a question of editorial balance. The idea of putting this into  
> the progress events spec is twofold.
>
> First, at minimum a specification should be able to simply refer to  
> Progress Events and say "do it like that" (hence the macro idea, which I  
> have tried to include already but will revise/refine a bit).

That definitely makes sense, though please take into consideration that for cross-origin loads exposing the file size cannot be done until all HTTP headers have been received and the requested resource has opted in with CORS. Otherwise we make it easier to do port sniffing. Since interaction with CORS will have to be defined by the specification defining the API (due to things such as source origin) the specifics of event dispatching will also need to be defined there and can probably not be done in a generic way. (Unless you make it integrate well with CORS semantics somehow I suppose, but that might just make matters more confusing.)

Also, as currently phrased it seems to place limitations on specifications. E.g. if we want to introduce a timeout event in XMLHttpRequest for a specific operation the specification currently requires user agents to also dispatch a load/error/abort event in such scenarios which we do not want I think.


> Second, it should provide a reasonable default - if specifications are  
> defining something significantly different then the defaults themselves  
> should be changed to match that. But if they are not, then it is saving  
> specifications from guessing what makes sense as a default behaviour...

It seems to do a little more than saving specifications from guessing :-)


>> I can also see some value in this specification providing macros. E.g.  
>> defining what it means to "dispatch a progress event called x" so that  
>> not every specification has to do that again and that they are  
>> encouraged to do the same thing with regards to whether events bubble,  
>> can be cancelled, etc. (HTML5 does this as well for some event types.)
>
> Indeed.

Will you provide this? This is effectively what I need for XMLHttpRequest Level 2.


Also, section 3 still talks about the now renamed "start" event. Furthermore, it also suggests the total member includes the request and response metadata. I think we should restrict it to the entity body.


-- 
Anne van Kesteren
http://annevankesteren.nl/

Received on Saturday, 13 June 2009 11:54:51 UTC