Fwd: Re: New progress event draft

Comments forwarded with permission... answers inline below

------- Forwarded message -------
From: "Ellen Siegel" <Ellen.Siegel@Sun.COM>
To: "Charles McCathieNevile" <chaals@opera.com>
Cc: "w3c-svg-wg@w3.org" <w3c-svg-wg@w3.org>, "Jean-Yves Bitterlich" <Jean-Yves.Bitterlich@Sun.COM>
Subject: Re: New progress event draft
Date: Mon, 19 Mar 2007 13:24:39 -0700

Here are some comments, and a few requests for clarifications, on the draft at http://dev.w3.org/cvsweb/~checkout~/2006/webapi/progress/Progress.html?rev=1.9.

initProgressEvent:

 Why are the comments on the initProgressEvent typeArg, cancelableArg, and canBubbleArg parameters written out instead of being "Refer to the event.initEventNS() method for a description of this parameter"?

CMN: Because I copied and pasted. I don't mind either way (there is an issue listed, because there are arguments for keeping something in a whole spec as well as for making things work together by referring appropriately. I hadn't thought about since noting the issue, but it seems to me better to refer.

(also, typo in the canBubbleArg description, it says "canceled" instead of "canBubble")

CMN: I'll fix that.

 Can you clarify the possible values for the total parameter of initProgressEvent? Is this just a guesstimate, or must it either be accurate or zero?

CMN: We can clarify it as seems reasonable. I would suggest that it should be accurate (with lengthComputable set to true) or zero (with lengthComputable set to false), but we have no way of knowing if a total is accurate until we have finished anyway.

 It is probably worth clarifying the constraint on the value of total (must be zero if lengthComputable is false) in the parameter description.  How should implementation handle the case where totalArg specified in the initXX is negative? or is zero when lengthComputable is true? or is not zero when lengthComputable is false?

CMN: Where lengthComputable is true and total is zero, it should be assumed that the thing is of zero length (a legitimate value). I am not sure how implementations should handle incorrect totals. If they notice the thing has finished successfully before the total size, I think they should just finish and ignore total. If they are not finished, and get more data after overrunning the declared total, they should just behave as if they don't know the total (unless it changes...).

What is the expected behavior if initProgressEvent(NS)() is called with eventArg set to one of the begin, load, etc,  but set canBubbleArg to true? Is it allowed or disallowed?  (spec stats: These events /must not/ bubble, and /must/ be cancelable, but there is no guidance on how to deal with error cases)

CMN: We can either change the must not to shold, or clamp the values for the event. I don't have a preference one way or the other.

Any guidance on the expected behavior if the value provided for  loadedArg is not positive, i.e., zero or negative?

CMN: zero is a reasonable value. I suggest if it is not a non-negative integer we just clamp it to the closest number, or zero...

In initProgressEventNS,

 Copy/Paste Typo:  in the description of initProgressEventNS, it refers to initProgressEvent (no NS).

CMN: will fix

 can namespaceURI be null?

CMN: Yes, and it must be for the events we have defined.

 same comment as above: the description for canBubbleArg refers to "can be canceled"

CMN: same response - will fix...

(many of the comments from initProgressEvent also apply to initProgressEventNS, but I won't repeat them.)

CMN: OK. I'll try to interpret intelligently...

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 Monday, 19 March 2007 23:56:41 UTC