Re: Progress Events normative text

On Sat, 13 Jun 2009 13:54:10 +0200, Anne van Kesteren <annevk@opera.com>  
wrote:

> 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.

OK. One of the things I intended to keep leaving to the "host" spec was  
definining what the size actually refers to.

> 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.)

Can you elaborate?

> 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

Yes, that's the way I understand it.

> which we do not want I think.

Why not? (thinking out loud, it makes sense to me that the requirement  
becomes a "should", enabling specs to define things in different ways  
while providing some clear guidance to people who don't want to guess. But  
if you have some clearer thoughts about use cases and requirements that  
would be helpful...)

>> 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 :-)

Then what it says doesn't match what I intend it to say. Some more  
detailed explanation would help me spot where the problems are.

>>> 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.

Yes. (There is an attempt at it already, but one that it pretty basic).

> 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.

Err, in normative text or in a random example? I intend to add more (and  
more realistic) examples - if you have some text from e.g. XHR that I  
could use, that would probably be very helpful.

In some cases it seems reasonable to restrict things to the entity body,  
in other cases the response text is important - or both are... which is  
why I plan to continue leaving that to the "host" spec.

cheers

Chaals

-- 
Charles McCathieNevile  Opera Software, Standards Group
     je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals       Try Opera: http://www.opera.com

Received on Monday, 15 June 2009 15:01:42 UTC