Comments forwarded with permission... answers inline below ------- Forwarded message ------- From: "Ellen Siegel" <[EMAIL PROTECTED]> To: "Charles McCathieNevile" <[EMAIL PROTECTED]> Cc: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>, "Jean-Yves Bitterlich" <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] Try Opera 9.1 http://opera.com
