W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2009

Re: Progress Events normative text

From: Charles McCathieNevile <chaals@opera.com>
Date: Sat, 30 May 2009 09:26:40 +0200
To: "Anne van Kesteren" <annevk@opera.com>, "Ian Hickson" <ian@hixie.ch>
Cc: public-webapps@w3.org
Message-ID: <op.uuqeyqnbwxe0ny@widsith.local>
On Wed, 22 Apr 2009 16:57:41 +0200, Anne van Kesteren <annevk@opera.com>  

> On Tue, 10 Mar 2009 21:35:15 +0100, Ian Hickson <ian@hixie.ch> wrote:
>> I continue to think that RFC2119 terms are overused, used unnecessarily
>> and redundantly in a manner that will cause future pain, and used in
>> manners that do not directly map to clear testable features, which I  
>> think is problematic. However, I don't really know how to convince you  
>> that this is a real problem.
> I just took a look at the draft and agree with this assessment.
> As far as I can tell the only requirements this specification needs to  
> make are regarding how to implement the interface. When events are  
> dispatched etc. is up to other specifications.
> I can see some value in this specification giving advice as to what the  
> names of the events should be and what order they should be dispatched  
> in, but that should only be advice to specification authors, not  
> requirements on user agents. The requirements on user agents should be  
> elsewhere.

This is a question of editorial balance. The idea of putting this into the  
progress events spec is twofold.

First, at minimum a specification should be able to simply refer to  
Progress Events and say "do it like that" (hence the macro idea, which I  
have tried to include already but will revise/refine a bit).

Second, it should provide a reasonable default - if specifications are  
defining something significantly different then the defaults themselves  
should be changed to match that. But if they are not, then it is saving  
specifications from guessing what makes sense as a default behaviour...

> I can also see some value in this specification providing macros. E.g.  
> defining what it means to "dispatch a progress event called x" so that  
> not every specification has to do that again and that they are  
> encouraged to do the same thing with regards to whether events bubble,  
> can be cancelled, etc. (HTML5 does this as well for some event types.)




Charles McCathieNevile  Opera Software, Standards Group
     je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals       Try Opera: http://www.opera.com
Received on Saturday, 30 May 2009 07:27:28 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:16 UTC