Re: New draft of Progress events

Björn,

thanks for the comments. Some of the simple stuff I did already, and is now
reflected in another draft  
http://dev.w3.org/cvsweb/~checkout~/2006/webapi/progress/Progress.html?rev=1.4
but some I decided not to spend my Saturday night working on, and there  
are a
couple of questions below too.

On Sat, 27 Jan 2007 13:38:07 -0500, Bjoern Hoehrmann <derhoermi@gmx.net>  
wrote:

> Looking at rev 1.3,
>
> * The abstract should say the document defines event types, not "an
> event".

Done.

> * I am unsure what "onprogress" and "onloadprogress" are supposed to
> be in the context of the document.

They are supposed to be gone. And they are, now.

> * I do not understand e.g. "A ProgressEvent occurs ...". ProgressEvent
> is an event interface, interfaces and even instances of objects that
> implement an event interface do not occur, only events occur.
>
> * Similarily, "The user agent may dispatch a ProgressEvent event" is
> rather poor.

tried to clarify these two.

> * I suggest not to use SVG event attributes in the example, since the
> event types are supposed to be markup-language independent, the ex-
> amples should be aswell. Use addEventListener instead.

good point - done.

> * text/ecmascript is obsolete and should be application/ecmascript in-
> stead.

Done

> * the individual event types should be described fully in a manner
> similar to how DOM Level 3 Events defines its event types. This in-
> cludes adding information about whether the events are cancelable,
> whether they bubble, what namespace they are in, and so on. Where
> that is unclear as yet, add a note instead.

Agree. To do...

> * the example script code will raise an exception if the size is not
> known, which essentially breaks the whole example. I do not think
> this is how the event types should be used.

Yeah, I was thinking about this today. I was also thinking of a different
example that just had a text counter, but being a dreadful scripter at the  
best
of times didn't get around to writing it. So I agree, adjusted the example  
to
look for the error case, but didn't do the rest yet. (Note that the  
example is
already fragmentary...)

> * there is also no need to use scripting to change the xlink:href
> attribute, you could easily use <set> instead.

I think it is more obvious what is going on if you use the script to make  
the
change - although it is a matter of personal taste as far as I can tell. If
there is an outcry in favour of set I can happily change it, but left it  
alone
for now.

> * also note that the example uses SVG 1.1 but SVG 1.1 does not have
> an onprogress event attribute. If it's supposed to be an SVG 1.2
> document, you should use xml:id in place of the id attribute.

right. Changing to addEventListener (as you suggested above) means there  
is no
onprogress attribute.

> * The progressBar.setAttributeNS(svgNS, ... are all wrong, the name-
> space is null in those cases.

I thought they were SVG attributes and so using the namespace is fine, or  
am I
missing something?

> * for .total and .loaded it is unclear what bytes they refer to. Do
> they include protocol overhead like headers and markers, or to the
> actual content?

Interesting question. I believe we discussed it in passing at the meeting  
and
came up with the actual content only, not the overhead stuff. I put it  
like that
and will raise an issue.

> Before or after removing transfer and/or content encodings?

I have said before, but again I will raise an issue.

> * most of the method definitions should defer to DOM Level 3 Events
> for their semantics, in a manner similar to DOM Level 3 Events.

Yeah. To do, but not tonight (unless someone gives me the text to paste :)  
)

> * s/namnespaceURI/namespaceURI/

fixed. (Probably other typos were introduced though)

> * All parameters of initProgressEvent/NS should end in Arg.

ok

> * The init method's prototypes are wrong, the arguments should be
> exactly those of initEvent/NS in the correct order, followed by
> arguments for the additional context information.

? I don't get what you mean.

> * The References section should follow the conventions explained in
> http://www.w3.org/2001/06/manual/

Agree. To do.

> With these changes we can probably publish the document.

As soon as you are happy to have a draft (note that it doesn't represent
consensus of the WG at this stage, just the ability or otherwise of the  
editor
to put a draft together), please say so.

cheers

Chaals

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

Received on Sunday, 28 January 2007 00:56:09 UTC