Re: Progress Events normative text

On Sat, 10 Jan 2009 00:28:42 +0100, Ian Hickson <ian@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 passed, and lengthComputable is false, the
>> > # user agent must override this and set the value to zero.
>> >
>> > This would mark the first time an initEvent method prevented a script  
>> > from initialising an event to an arbitrary value. I think that's a bad
>> > precedent to set. Could you elaborate on why we want this requirment?
>>
>> As a defined method for handling error states that doesn't force user
>> agents and interlocking scripts to work out how to deal with any
>> arbitrary values but only those which make sense.
>
> Why would a user agent ever have to deal with these?
>
> The scripts are the ones that would be firing this event, so presumably  
> if an author has a reason to create a custom event with the value set to
> non-zero, there would be no harm in doing so.

Fair enough. I removed the requirement.

>> If you want this changed, could you elaborate on why, and raise an issue
>> in the Web-apps issue tracker?
>
> Because the spec is defining a reusable interface and it should work
> consistently with the rest of the platform to be usable. We don't know
> what people will be doing with these events.
>
> Filed issue-79.

Do you think this is now resolved?

> Regarding the editorial notes -- I strongly disagree with the idea that
> redundancy in conformance statements is good; in my experience it leads  
> to an unstoppable stream of misunderstandings where first one person
> reads one requirement and assumes that it tells the complete story, then  
> someone else reads the other and assumes the same, where in fact they are
> both telling only part of the story. It also leads to contradictions
> (when only one is fixed, especially relevant when the redundancy is
> cross-spec).
>
> This is especially insidious in this case because the spec's entire
> purpose is to be reused by other specifications: because the spec doesn't
> provide any "hooks" as I proposed, there is no choice in other specs but
> to have yet more redundancy, making the entire house of cards very
> brittle. I think this will cause us no end of problems going forward.

This is one of a set of balancing acts an editor performs.

I have attempted to ensure that the conformance statements are consistent,  
such that the only way to make a mistake of this nature will be to ignore  
or violate a coformance requirement. That is something the spec cannot  
prevent, but I think  the spec has done what is necessary to reduce the  
risk of re-use leading to errors (assuming a moderately competent reader)  
by being reasonably short, clear and precise.

There may be problems with what is actually in this spec itself, which  
would be a seperate concern. Is there a concrete problem here?

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

Received on Thursday, 5 March 2009 12:56:05 UTC