Re: Requirements... Re: Progress events progress...

On Sun, 24 Feb 2008, Charles McCathieNevile wrote:
> > 
> > Incidentally, I _really_ don't understand the definition of the User 
> > Agent conformance class:
> > 
> > | A conforming user agent implements all the requirements described for
> > | user agents throughout this specification. A conforming user agent
> > | should implement all the recommendations for user agents as well.
> > 
> > First, why is there a conformance requirement in the definition of the 
> > conformance class to which it applies?
> [...]
> No. You MUST do the things that are a MUST, and you SHOULD do the things 
> that are a SHOULD. That struck me as a very straighforward proposition. 
> Maybe I will try to say it more in those words.

Oh, I see. I misread it; I didn't notice the distinction between the 
"requirement" and "recommendation" parts. But I'm confused as to why we 
need to say this -- isn't this what RFC2119 says? We don't need to define 
SHOULD and MUST, that's what they mean, they're already defined.

> > Frankly, as the editor of a spec that tries to use this spec, I'm not 
> > sure what would be best. I'm thinking that one option would be to 
> > change the focus of the Progress Events spec to be more of a guide, 
> > with the normative parts being only the definition of the IDL, with 
> > its methods defined in line with the DOM Events spec and the DOM 
> > Bindings spec, and with everything else just left up to the specs 
> > using it. The spec would then give a guide as to what event names are 
> > expected , in what order, but without making this normative.
> I think it is useful to define the events normatively to allow for 
> interoperable use of them amongst multile specifications - for example 
> user agents handling SVG and HTML.

That makes sense, assuming the normativeness is on specifications. It's 
not clear to me exactly what the state is now.

> > (I've already had to deviate from what this spec requires, mostly due 
> > to having more events to fire.)
> In what way did you have to deviate?

In the <video>/<audio> stuff: 'loadstart' is 'begin', though I'm not sure 
why. This might be fixable. None of the final messages will fire if the 
browsing context navigates. Any number of messages of the given types 
might be fired in any order on the element if directly done using 

In the cache manifest stuff: I need to redo this anyway, so this might 
change, but right now there's a whole set of events that don't match what 
Progress Events requires. Right now it goes:

         +-> error
         +-> noupdate
         |            |
        \|/           |
      progress -->----'
         +-> error
         |            |
        \|/          \|/
       cached    updateready

...and none of the events are currently ProgressEvent events, though I 
expect that to change (at least for 'progress'). It's also possible that 
for this set of events, loaded and total would be more useful as a count 
of total resources to fetch / fetched than as a count of bytes. 
Alternatively, both might need to be made available (so e.g. I might need 
to subclass ProgressEvent to provide more details).

> The spec allows you to add any more events you want, it just defines 
> particular events and the relation between them.


> Does your work on this change the names or order of the things defined 
> in the current draft, which were left that way because they matched 
> earlier drafts that were implemented in user agents or just add new 
> events that you define yourself?

I'm not sure why 'begin' is not called 'loadstart' in the <video> section, 
but other than that those are just new events. I'm not sure what the 
implementation status is. For the appcache stuff it's a different set of 
events, but that's because it's doing something quite different, and I 
just need 'progress' for the middle of it.

> (Do you have a handy pointer? I assume you mean the HTML spec but for 
> some reason that is not currently loading for me)

Yes, I meant these two sections: should always work, but if that fails you can 
also try which is about as reliable but 
they shouldn't be down at the same time. (The latter is a much bigger 
file, though, so it might cause browser problems.)

> > To make this slightly more useful, maybe some "macros" could be 
> > defined, similar to the "fire a simple event" macro I have in HTML5, 
> > but like "fire a progress event" which takes "arguments" like the 
> > event name, the progress, the total, and the target element, with the 
> > "macro" setting up the bubbling and canceling behaviour, etc, and 
> > "returning" whether or not the event's default action should fire.
> I am not sure about this.

Well, I need one of those anyway, whether it's in HTML5 or elsewhere isn't 
a big deal. It would certainly go a long way towards ensuring that the 
specs that use progress events are compatible, though.

> > I don't know if it makes sense to have authoring conformance 
> > requirements for this spec at all.
> I believe it does. Which is why they are in the spec.

Fair enough. In that case, though, the requirements really need to be 
dramatically clarified. Right now the spec mixes imperative text and 
normative requirements, as well as being very unclear about what 
requirements lie on specs vs implementations and authors.

> Do you want a formal issue raised?

How do you mean?

Ian Hickson               U+1047E                )\._.,--....,'``.    fL       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Sunday, 24 February 2008 22:42:29 UTC