Re: New draft of Progress events

* Charles McCathieNevile wrote:
>I have made a new editor's draft available, and in order to get wider  
>comment I would like to move it to a W3C Public Working Draft.
>
>If people are happy to do this, please say so on the maikling list ...

Looking at rev 1.3,

  * The abstract should say the document defines event types, not "an
    event".

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

  * 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.

  * 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.

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

  * 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.

  * 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.

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

  * 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.

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

  * 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? Before or after removing transfer and/or content
    encodings?

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

  * s/namnespaceURI/namespaceURI/

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

  * 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.

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

With these changes we can probably publish the document.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

Received on Saturday, 27 January 2007 18:38:18 UTC