Re: Progress Events normative text

Focusing just on things that are non-editorial in nature:

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.


> > 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.


> > 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?


> > # 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.


> > 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.)


> > # 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.


> > 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.


> 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.


> Yes, considering this would be valuable. Are there any plans to split 
> this work out in order to provide some sense of stability in this 
> decade, for the various non-HTML specifications that make use of 
> Progress Events?

No, but the task source stuff is pretty stable. (There's not really 
anything to change, I mean, it's just describing an event queue.)



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.

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

Received on Friday, 9 January 2009 23:29:20 UTC