On Sat, 13 Jun 2009 13:54:10 +0200, Anne van Kesteren <ann...@opera.com>
wrote:
On Sat, 30 May 2009 09:26:40 +0200, Charles McCathieNevile
<cha...@opera.com> wrote:
On Wed, 22 Apr 2009 16:57:41 +0200, Anne van Kesteren <ann...@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