Re: Progress Events normative text
On Sun, 21 Jun 2009 00:54:22 +0200, Charles McCathieNevile cha...@opera.com wrote: On Thu, 18 Jun 2009 19:28:48 +0200, Jonas Sicking jo...@sicking.cc wrote: At the very least we can define that for HTTP request, headers are not used. For things like WebSocket and FutureAwesomeMegaAlienProtocol it might make sense to do something different, perhaps. Agreed. It's not clear to me you'd always want to use the same object though. E.g. for the simple case of Web Sockets no length is known and therefore it might be more interesting to get information about how many characters have been received so far rather than bytes. Though maybe this is too much complexity for little benefit. Right. This is ISSUE-4 which was resolved to do it the way the spec does it now (after having it defined in the spec when it was Web API issue 108). While it makes sense to describe what most things do, this seems a case where it might be reasonable to leave it to the spec. Although I am open to defining it (like other stuff) with a default of not counting transaction metadata/overhead, saying that specs can choose to override that specifically if they need to. Maybe just define a concept e.g. message length and for HTTP you define it to be the entity body of the request/response and for other protocols you leave it until when we get there. -- Anne van Kesteren http://annevankesteren.nl/
Re: Progress Events normative text
On Thu, 18 Jun 2009 19:28:48 +0200, Jonas Sicking jo...@sicking.cc wrote: On Wed, Jun 17, 2009 at 5:49 AM, Anne van Kesterenann...@opera.com wrote: On Mon, 15 Jun 2009 17:00:46 +0200, Charles McCathieNevile cha...@opera.com wrote: On Sat, 13 Jun 2009 13:54:10 +0200, Anne van Kesteren ann...@opera.com wrote: That definitely makes sense, though please take into consideration that for cross-origin loads exposing the file size cannot be done until all HTTP headers have been received and the requested resource has opted in with CORS. OK. One of the things I intended to keep leaving to the host spec was definining what the size actually refers to. I'd think we would like this to consistently refer to the entity body for all usage of progress events as to not confuse people using the API. It seems odd to take great care in order and naming but not in consistent implementation of the event objects. At the very least we can define that for HTTP request, headers are not used. For things like WebSocket and FutureAwesomeMegaAlienProtocol it might make sense to do something different, perhaps. Right. This is ISSUE-4 which was resolved to do it the way the spec does it now (after having it defined in the spec when it was Web API issue 108). While it makes sense to describe what most things do, this seems a case where it might be reasonable to leave it to the spec. Although I am open to defining it (like other stuff) with a default of not counting transaction metadata/overhead, saying that specs can choose to override that specifically if they need to. cheers Chaals -- 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
Re: Progress Events normative text
On Wed, Jun 17, 2009 at 5:49 AM, Anne van Kesterenann...@opera.com wrote: On Mon, 15 Jun 2009 17:00:46 +0200, Charles McCathieNevile cha...@opera.com wrote: On Sat, 13 Jun 2009 13:54:10 +0200, Anne van Kesteren ann...@opera.com wrote: That definitely makes sense, though please take into consideration that for cross-origin loads exposing the file size cannot be done until all HTTP headers have been received and the requested resource has opted in with CORS. OK. One of the things I intended to keep leaving to the host spec was definining what the size actually refers to. I'd think we would like this to consistently refer to the entity body for all usage of progress events as to not confuse people using the API. It seems odd to take great care in order and naming but not in consistent implementation of the event objects. At the very least we can define that for HTTP request, headers are not used. For things like WebSocket and FutureAwesomeMegaAlienProtocol it might make sense to do something different, perhaps. / Jonas
Re: Progress Events normative text
On Mon, 15 Jun 2009 17:00:46 +0200, Charles McCathieNevile cha...@opera.com wrote: On Sat, 13 Jun 2009 13:54:10 +0200, Anne van Kesteren ann...@opera.com wrote: That definitely makes sense, though please take into consideration that for cross-origin loads exposing the file size cannot be done until all HTTP headers have been received and the requested resource has opted in with CORS. OK. One of the things I intended to keep leaving to the host spec was definining what the size actually refers to. I'd think we would like this to consistently refer to the entity body for all usage of progress events as to not confuse people using the API. It seems odd to take great care in order and naming but not in consistent implementation of the event objects. Since interaction with CORS will have to be defined by the specification defining the API (due to things such as source origin) the specifics of event dispatching will also need to be defined there and can probably not be done in a generic way. (Unless you make it integrate well with CORS semantics somehow I suppose, but that might just make matters more confusing.) Can you elaborate? Exposing file size for cross-origin loads is a concern as I understand it. It makes it easier to do port scanning. So in order to prevent that resources loaded in a cross-origin fashion would have to opt in to sharing this information (much like they opt in to share the resource itself) and therefore they have to follow the model that CORS outlines. Also, as currently phrased it seems to place limitations on specifications. E.g. if we want to introduce a timeout event in XMLHttpRequest for a specific operation the specification currently requires user agents to also dispatch a load/error/abort event in such scenarios Yes, that's the way I understand it. which we do not want I think. Why not? (thinking out loud, it makes sense to me that the requirement becomes a should, enabling specs to define things in different ways while providing some clear guidance to people who don't want to guess. But if you have some clearer thoughts about use cases and requirements that would be helpful...) There's no reason for XHR2 to also dispatch one of load/error/abort if it already does both timeout and loadend. And I think you want to know the difference by the request being aborted due to a timeout versus a script or user initiated abort. Even SHOULD seems too strong for this in my opinion. 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... It seems to do a little more than saving specifications from guessing :-) Then what it says doesn't match what I intend it to say. Some more detailed explanation would help me spot where the problems are. User agents must ensure that these events trigger event listeners attached on Element nodes for the relevant event and on the capture and target phases. does not work for XMLHttpRequest or XMLHttpRequestUpload. Neither is an Element node. Also, this requirement should be present in DOM Events and it would help I think if it was not restated here. (If you think it helps make it a non-normative note about DOM Events.) Specifications should use the events defined in this specification in preference to other events (e.g. in a different namespace, or with a different name) that offer the same functionality. is another example. The section Event firing order duplicates text from e.g. XMLHttpRequest Level 2 which gives confusing and potentially contradictory requirements as I outlined above. I think that just as in CORS it should be advice given to API specifications, not requirements. Given that other specifications probably need to be fairly specific about when to dispatch certain progress events due to cross-origin loads etc. I still think it makes more sense to have no requirements in the specification regarding dispatching and have it be just an event name registry and interface description. On top of that you could have a single definition of what it means to dispatch a progress events: To *dispatch a progress event called x on y*, dispatch an event named x that implements the ProgressEvent interface on y with the members of the event object set as follows: namespace null bubbles false cancelable false lengthComputable true if the size of the resource is known. false otherwise. loaded The size of the entity body transferred so far. total The size of the entity body or zero if this is not known. Also, section 3 still talks about the now renamed start event. Furthermore, it also suggests the total member includes the request and
Re: Progress Events normative text
On Sat, 30 May 2009 09:26:40 +0200, Charles McCathieNevile cha...@opera.com wrote: On Wed, 22 Apr 2009 16:57:41 +0200, Anne van Kesteren ann...@opera.com wrote: 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). That definitely makes sense, though please take into consideration that for cross-origin loads exposing the file size cannot be done until all HTTP headers have been received and the requested resource has opted in with CORS. Otherwise we make it easier to do port sniffing. Since interaction with CORS will have to be defined by the specification defining the API (due to things such as source origin) the specifics of event dispatching will also need to be defined there and can probably not be done in a generic way. (Unless you make it integrate well with CORS semantics somehow I suppose, but that might just make matters more confusing.) Also, as currently phrased it seems to place limitations on specifications. E.g. if we want to introduce a timeout event in XMLHttpRequest for a specific operation the specification currently requires user agents to also dispatch a load/error/abort event in such scenarios which we do not want I think. 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... It seems to do a little more than saving specifications from guessing :-) 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.) Indeed. Will you provide this? This is effectively what I need for XMLHttpRequest Level 2. Also, section 3 still talks about the now renamed start event. Furthermore, it also suggests the total member includes the request and response metadata. I think we should restrict it to the entity body. -- Anne van Kesteren http://annevankesteren.nl/
Re: Progress Events normative text
On Wed, 22 Apr 2009 16:57:41 +0200, Anne van Kesteren ann...@opera.com wrote: On Tue, 10 Mar 2009 21:35:15 +0100, Ian Hickson i...@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.) Indeed. cheers Chaals -- 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
Re: Progress Events normative text
On Tue, 10 Mar 2009 21:35:15 +0100, Ian Hickson i...@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. 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.) -- Anne van Kesteren http://annevankesteren.nl/
Re: Progress Events normative text
On Thu, 5 Mar 2009, Charles McCathieNevile wrote:
I think it is wrong to make content non-conforming because it
fires events in a fashion that isn't consistent with this draft.
It seems odd to me to say that content is not allowed to work around
bugs in browsers, for instance.
Content is allowed to do whatever it wants.
Ok now I'm really confused. Here you say that content is allowed to do
whatever it wants, but then you say:
However, only some content is defined as conforming
...which as far as I can tell is a direct contradiction.
If something is non-conforming, that means that the spec is prohibiting
it, that it is not allowed. That's what it means to make something non-
conforming, as I understand it.
and in this case, content that does things not predicted by the spec is
defined as non-conforming. This avoids attempting to ascribe motive to
the content.
I don't understand what this means.
I still think it is wrong for us to make content non-conforming for firing
events that use the ProgressEvents interface in a manner different than
what the spec describes.
# 2.3 Interface definitions
This is the one section that really needs normative text, since it
is the one section that is really defining new features. However,
as far as I can tell, it really doesn't define anything
normatively. For example, the attributes have no UA requirements.
Is lengthComputable supposed to throw, return true, return false,
have any side-effects? Same for the others.
This problem still exists.
Perhaps I am missing something here. They are attributes. They have
values, which are described. In what circumstances would they throw, or
have side effects, or return anything except their value?
If I run the following script:
var e = document.createEvent('ProgressEvent');
e.initProgressEvent('load', true, true, true, 1, 2);
alert(e.loaded);
...what number is alerted? What must conformance criteria requires this?
As far as I can tell, nothing in the spec today requires that the
attributes have any particular value.
Similarly if I init the event with lengthComputableArg set to false and
totalArg set to 100, what does the must in the definition of total
mean? Does it mean it returns zero? The conformance criteria are very
confusingly written in this section.
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.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Progress Events normative text
On Sat, 10 Jan 2009 00:28:42 +0100, Ian Hickson i...@hixie.ch wrote: On Fri, 21 Nov 2008, Charles McCathieNevile wrote: I think it is wrong to make content non-conforming because it fires events in a fashion that isn't consistent with this draft. These are conformance requirements. Nothing forces content to be conforming, but it is valuable to have a clear explanation of what conformance means (otherwise why would you have bothered commenting on the need for such clarity). There are many reasons for doing so... There are some reasons why this might be done, but I don't see any example sufficiently compelling to effectively abrogate a sense of conformance for content. It seems odd to me to say that content is not allowed to work around bugs in browsers, for instance. Content is allowed to do whatever it wants. However, only some content is defined as conforming, and in this case, content that does things not predicted by the spec is defined as non-conforming. This avoids attempting to ascribe motive to the content. Do these requirements mean that if a script calls dispatchEvent(), that the UA would be non-conforming if it dispatched the event? e.g. if the script fires 'abort', then 'load', then 'progress', then 'loadstart' twice, is the UA non-conforming? The text is unclear. If the script (content) calls for the events to be dispatched in a non-conforming order, then the content is non-conforming. That a conformant UA can support non-conformant content is unclear - I will clarify that in the text. This still seems unclear to me in the text. I added a more explicit note in the conformance section of rev 1.30 Below the table, there are some paragraphs that again may not make sense: # User agents must implement these events such that by default the events # do not bubble, and are not be cancelable. What does it mean for an event to not bubble by default? Or not be cancelable by default? Events don't have defaults. User agent implementations of events have defaults - either the user agent (absent other considerations) makes the event bubble, or it doesn't. Could you illustrate some way in which one of these events could be fired without an explicit decision on whether the event bubbles or is cancelable, such that the default has an effect? Or to put it another way, could you show a test case that tests this requirement? Such a test case would require a specification that used progress events without saying what they do, and testing whether they bubble. # Two kinds of initialisation methods are provided: one # (initProgressEventNS) in which the namespace is required and must be # null (any event in another namespace is not defined by this # specification), and one (initProgressEvent) which assigns the null # namespace automatically. I don't understand what it means for the argument to be required to be null. Why shouldn't people use the ProgressEvent interface with custom events in their own namespace? There is no prohibition on or recommendation against doing that. This specification simply refrains from any attempt to define what such events might mean. I don't understand what this means: # Two kinds of initialisation methods are provided: one # (initProgressEventNS) in which the namespace is required and must be # null [...] ...if it does not mean that the namespace must be null. If you mean namespace must be null _when used to create events defined in this specification_ then that should be said, though it is redundant with earlier text. changed. How does this interact with equivalent requirements in other specifications? Does this mean that two events should be fired, one for the requirement in HTML5, say, and one for this spec? No. The event in HTML5 that is the event initially defined in this spec, with further specification relevant to HTML5-specific features (if I am not mistaken). It is very confusing to me to have two specs saying that an event must be fired, if we are only expecting one ever to be fired. (This is why I would have preferred this spec to define functions or macros that other specs could then invoke to fire the events.) Added a section on Firing Progress Events # 2.3 Interface definitions This is the one section that really needs normative text, since it is the one section that is really defining new features. However, as far as I can tell, it really doesn't define anything normatively. For example, the attributes have no UA requirements. Is lengthComputable supposed to throw, return true, return false, have any side-effects? Same for the others. This problem still exists. Perhaps I am missing something here. They are attributes. They have values, which are described. In what circumstances would they throw, or have side effects, or return anything except their value? The only requirement that _is_ given and isn't redundant with WebIDL is: # If any other parameter is
Re: Progress Events normative text
Hi Ian, On Fri, 31 Oct 2008 15:24:14 -0400, Ian Hickson [EMAIL PROTECTED] wrote: http://dev.w3.org/2006/webapi/progress/Progress.html I guess http://dev.w3.org/cvsweb/~checkout~/2006/webapi/progress/Progress.html?rev=1.25 in particular, since that was the latest draft when I received this email. The draft says: # The terms must, should, may, must not, should not, are used in this # document in accordance with [RFC2119]... However, I think the terms are used a bit loosely so far. I will attempt to point out cases of this in the spec in this e-mail. ... # User agent # A user agent must implement all the requirements described for user # agents throughout this specification in order to be a conforming user # agent. A conforming user agent should implement all the recommendations # for user agents as well. Given the definition of must and should, this seems redundant. Having received several comments asking for real clarity on what is required (including from you), I am happy to stick with redundant statements, where they serve to repeat a requirement and don't cause confusion. # Content # Conforming content must generate and consume progress events in # accordance with the definitions of those events in this # specification, and in accordance with any additional conformance # requirements defined by a specification which describes an operation # that can lead to progress events being dispatched. I think it is wrong to make content non-conforming because it fires events in a fashion that isn't consistent with this draft. These are conformance requirements. Nothing forces content to be conforming, but it is valuable to have a clear explanation of what conformance means (otherwise why would you have bothered commenting on the need for such clarity). There are many reasons for doing so... There are some reasons why this might be done, but I don't see any example sufficiently compelling to effectively abrogate a sense of conformance for content. # 2.1 Event definitions The table comes before the concepts are introduced, which is confusing, because there are must requirements in the table that don't really make sense without context. On the other hand, introducing the concepts before the table breaks the principle of pyramid writing. Having a simple summary of a longer section be the first part of that section can aid overall comprehension of that section. Conversely, presenting the reader with a lot of prose that must be waded through can actually pose a significant barrier to efficient understanding of the content. The table does not stand on its own until the rest of the content is known, but it provides a shorthand that can be used to understand the whole section - and so for a repeat reader I believe it is a helpful shorthand (so long as it does not contradict what follows, or provide a misleading impression by omission of important data). Likewise for an initial reader it gives them a conceptual framework they can then adorn with the further information supplied afterwards, rather than requiring them to digest a lot of data before they have such a conceptual framework for processing it. For example, what does it mean for an event to be dispatched first? First relative to what? First relative to other events defined by this specification. Do you find that assumption unnatural? If so, what did you think it referred to? (It is possible to misunderstand anything, with a small effort. My goal in this spec is to make it *sufficiently clear*, so it is possible to understand it correctly with less effort than it takes to imagine an alternative meaning. Adding more prose to the specification /ipso facto/ makes misunderstanding more likely, so there is a tension between comprehensiveness and comprehensibility). However, in general I'm not sure that it makes sense for that table to have these requirements anyway. load, for example, fires in many more cases than the table suggests, and sometimes, indeed in the most common cases in HTML, load and error are not alternatives but are unrelated. I will look at clarifying the fact that statements are relative to things defined within the specification. Do these requirements mean that if a script calls dispatchEvent(), that the UA would be non-conforming if it dispatched the event? e.g. if the script fires 'abort', then 'load', then 'progress', then 'loadstart' twice, is the UA non-conforming? The text is unclear. If the script (content) calls for the events to be dispatched in a non-conforming order, then the content is non-conforming. That a conformant UA can support non-conformant content is unclear - I will clarify that in the text. I think it would be helpful to consider how to test this section without another spec. I think one would find it impossible to do so. Thus, and since another spec would define the order with MUST-level requirements
