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
dispatchEvent().
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:
checking
|
+- error
|
+- noupdate
|
\|/
downloading
\|/
|
+---.
||
\|/ |
progress --'
|
+- error
|
+.
||
\|/ \|/
cachedupdateready
...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.
Cool.
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:
http://www.whatwg.org/specs/web-apps/current-work/multipage/section-offline.html#offline
http://www.whatwg.org/specs/web-apps/current-work/multipage/section-video.html#media
http://www.whatwg.org/html5 should always work, but if that fails you can
also try http://www.w3.org/html/wg/html5/ 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
