Re: New Progress Events spec

On Mar 6, 2007, at 10:39 PM, Charles McCathieNevile wrote:

> On Wed, 07 Mar 2007 14:13:58 +1100, Maciej Stachowiak  
> <> wrote:
>> On Mar 6, 2007, at 6:02 PM, Charles McCathieNevile wrote:
>>> 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.


Received on Wednesday, 7 March 2007 12:51:49 UTC