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