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 <[EMAIL PROTECTED]>
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
[EMAIL PROTECTED] Try Opera 9.1 http://opera.com
