On Mar 6, 2007, at 10:39 PM, Charles McCathieNevile wrote:
On Wed, 07 Mar 2007 14:13:58 +1100, Maciej Stachowiak
<[EMAIL PROTECTED]> wrote:
On Mar 6, 2007, at 6:02 PM, Charles McCathieNevile wrote:
http://dev.w3.org/cvsweb/~checkout~/2006/webapi/progress/
Progress.html?rev=1.8
I would appreciate review, and in particular propose to publish
this spec as a First Public Working Draft more or less in its
current shape.
I think it's fine for FPWD, other comments notwithstanding.
Thanks, and thanks for the comments. I have made a new draft with
some changes incorporated as discussed below...
Comments on new draft:
- Style-wise, it might be clearer to introduce the ProgressEvent
interface first, and then describe the various events
- Italicizing the event names is confusing, especially since it
clashes. A monospace font and/or a link to the definition would be
more appropriate.
- It would be nice to have a table or the like of the event types and
their meaning, like the current DOM 3 Events draft has for the event
modules it defines. This will make it more clear what the spec is
actually defining.
- "begin" might not be the best name for the event at the start of
loading, since all sorts of processes can begin. For example, SMIL
1.0 has an event named "begin" that means something completely
different, and SMIL 2.0 has the uncomfortably similar "beginEvent".
May I suggest using "loadstart", as I originally proposed?
- "These events are in the null namespace. Initialisation methods are
provided in both namespaced and un-namespaced versions for use as
appropriate. This specification does not recommend one over the other."
- "User agents must dispatch a ProgressEvent of type load" -- I
suggest instead of language like this, the spec say things like "user
agents must dispatch a load event", the fact that the load event
should implement the ProgressEvent interface should be specified for
the event type. Similarly for the other events.
- Spec should consistently use "dispatch" rather than "fire".
This seems to be confusing the ProgressEvent interface, which
provides both kinds of init methods and doesn't recommend one or the
other, with the events defined by the spec ("these events"), which
definitely use the null namespace, and the spec shouldn't leave
options both ways.
Regards,
Maciej
