Re: ISSUE-78: HTML5 stalled and suspend progress events [Progress Events]
Cc'ed to SVG as well, since people there use progress events. Please reply to the Web Apps group (reply-to is set). On Sat, 25 Oct 2008 22:45:10 +0200, Web Applications Working Group Issue Tracker [EMAIL PROTECTED] wrote: ISSUE-78: HTML5 stalled and suspend progress events [Progress Events] http://www.w3.org/2008/webapps/track/issues/78 Raised by: Philip Jägenstedt On product: Progress Events http://www.w3.org/html/wg/html5/#mediaevents The events in HTML 5 fired for the media elements (video+audio) are called ProgressEvents and are intended to eventually refer to the Progress Events spec. Currently the HTML5 draft specifies two events not covered by the Progress Events draft: stalled and suspend We have previously discussed a stalled event, in the context of suggested timing for producing progress events. We decided not to set a specific timing, because the use cases vary a lot and so the appropriate timing of progress events does too. So we could add the event directly to this spec, as a convenience. I think the suspend event would be useful and am inclined to add it. Should there be an unsuspend event, or is it enough to just emit a new progress event signifying taht something started again? And do others think this is a useful addition or just extra work? These should be added to the draft, I suggest the following phrasing: If we add these, I like the suggested phrasing. Name / Description / How often? / When? stalled / The operation is unexpectedly not progressing / zero or more / May be dispatched zero or more times after a loadstart event, before any error, abort or load event is dispatched suspend / The operation is temporarily suspended / zero or more / May be dispatched zero or more times after a loadstart event, before any error, abort or load event is dispatched Rationale: Stalled is used to signal that the download is for some reason not progressing, but the user agent has not yet given up and fired an error event. In HTML5 this happens when no data has been received for approximately 3 seconds. Suspend is used to signal that the user agent is deliberately pausing the download. In the case of audio/video, the user agent may initially download only a portion of the file and fetch the rest only when/if the user plays the audio/video to a point where it is needed. 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: Call for Consensus - Selectors Last Call
Hear hear! Charles McCathieNevile wrote: Hi, Lachy thinks the latest editor's draft[1] is ready for Last Call, after responding to all the comments from last time (and removing the NSResolver). The disposition of comments[2] explains what happened to those comments. So this is a call for Consensus to publish the Editor's Draft [1] of the Selectors API spec as a Last Call. Please respond before Monday November 10. As always, silence is taken as assent but an explicit response is preferred. Opera supports publication of this draft as a Last Call. [1] http://dev.w3.org/2006/webapi/selectors-api/ [2] http://dev.w3.org/2006/webapi/selectors-api/disposition-of-comments.html cheers Chaals
Re: Call for Consensus - Selectors Last Call
Kartikaya Gupta [EMAIL PROTECTED] wrote:
On Fri, 31 Oct 2008 16:06:23 +0100, Charles McCathieNevile
[EMAIL PROTECTED] wrote:
So this is a call for Consensus to publish the Editor's Draft [1] of the
Selectors API spec as a Last Call. Please respond before Monday November
10. As always, silence is taken as assent but an explicit response is
preferred.
Opera supports publication of this draft as a Last Call.
[1] http://dev.w3.org/2006/webapi/selectors-api/
[2]
http://dev.w3.org/2006/webapi/selectors-api/disposition-of-comments.html
Is it just me or is the scope element somewhat under-defined in the
spec? The only mentions of it are in this sentence:
If the context node is a Document node, then the scope element is the
documentElement of the given document. If the context node is an Element
node, then the scope element is the same as the context node.
However, it doesn't say what the scope element does or why it's relevant,
nor does it have a reference to any other spec that explains this. I did a
quick search through the list archives (I haven't been following it too
closely) and it looks like the :scope pseudo-class will be defined in
another spec. I think that should be clarified, because otherwise it just
looks like a completely random sentence that would be better taken out
altogether.
I concur.
I've just read the spec through the start to finish for the first time in
many months, prompted by these announcements, and came up with a number of
questions. Then I've read through all the articles in the disposition of
comments, and found that the same issues have already been raised and
discussed at length, but it seems that in some cases, no changes or
clarifications have been made to the document in response. Perhaps the
meaning of the spec is obvious to those who have been actively working on
the document who know what assumptions to make, but they aren't clear to me.
I really think that the spec needs to nail down the answers to these
questions - just a simple sentence (or non-normative example) will do.
The specific questions I had (which I think I found the definitive answers
for in the mail archives):
1) What is the scope element for - it's only mentioned in one sentence?
2) Is an empty string actually a valid selector? If not, then the whole
null/undefined is an empty string discussion is irrelevant - it's simply a
syntax error.
3) Does the matching algorithm work on based on the entire tree that
contains the context node or just the sub-tree rooted at the context node? I
think this is easiest fixed by adding an example like the one in the
previous e-mail that I'm quoting and stating the expected result:
Also, since the scope element stuff was deferred to another spec, this
spec remains somewhat ambiguous (at least to me) about exactly what gets
selected in the following case:
html
body
div class=bar
div id=foo
div class=baz/div
/div
/div
/body
/html
document.getElementById('foo').querySelector('.bar .baz')
I believe the above querySelector call should return the baz div as
opposed to NULL, but it took me a few close readings of the spec to decide
on that. A clarifying example in the spec would be quite helpful on this
one.
After trawling through the comments, I also think that the answer is that it
works on the entire tree, and consequently the baz div should be the one and
only result.
--
Stewart Brodie
Software Engineer
ANT Software Limited
Re: ISSUE-78: HTML5 stalled and suspend progress events [Progress Events]
On Fri, 31 Oct 2008 19:31:50 +0100, Ian Hickson [EMAIL PROTECTED] wrote: On Fri, 31 Oct 2008, Charles McCathieNevile wrote: We have previously discussed a stalled event, in the context of suggested timing for producing progress events. We decided not to set a specific timing, because the use cases vary a lot and so the appropriate timing of progress events does too. So we could add the event directly to this spec, as a convenience. I think the suspend event would be useful and am inclined to add it. Should there be an unsuspend event, or is it enough to just emit a new progress event signifying taht something started again? And do others think this is a useful addition or just extra work? I don't think 'unsuspend' is that useful given that you can just detect 'progress'. Yeah, makes sense to me. I do think that including all the events specs invent that use ProgressEvents into the progress spec makes sense, since that way other specs will reuse them. Well, having them all is probably impossible (since people can write specs I can't have read yet) but including ones we know of seems reasonable. I still don't think ProgressEvents should really have (nor really can have) much in the way of normative text, so I don't think that it's really complicated to add events. These are both may in terms of user agents. I would expect to define them in such a way that conforming specs use as defined (that is effectively already the requirement, although I'll check that it makes sense with these added). I think it also makes sense to add a note that conforming specs and uesr agents *should* use the events defined rather than something else with equivalent functionality. I'm not sure it makes sense to make that a *must*. Thoughts? 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: ISSUE-78: HTML5 stalled and suspend progress events [Progress Events]
On Fri, 31 Oct 2008, Charles McCathieNevile wrote: I think it also makes sense to add a note that conforming specs and uesr agents *should* use the events defined rather than something else with equivalent functionality. I'm not sure it makes sense to make that a *must*. I think it makes more sense for spec authors to discuss things together and come to a common understanding of how to bring the platform forward (as we are doing here) than for specs to have a concept of a conforming specification, but that's just a personal preference. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Call for Consensus - Selectors Last Call
Kartikaya Gupta wrote:
On Fri, 31 Oct 2008 16:06:23 +0100, Charles McCathieNevile
[EMAIL PROTECTED] wrote:
[1] http://dev.w3.org/2006/webapi/selectors-api/ [2]
Is it just me or is the scope element somewhat under-defined in the
spec? The only mentions of it are in this sentence:
If the context node is a Document node, then the scope element is
the documentElement of the given document. If the context node is an
Element node, then the scope element is the same as the context
node.
However, it doesn't say what the scope element does or why it's
relevant, nor does it have a reference to any other spec that
explains this. I did a quick search through the list archives (I
haven't been following it too closely) and it looks like the :scope
pseudo-class will be defined in another spec.
It was added with the intention of referencing whichever spec :scope (or
whatever it gets called) gets defined in, which will most likely be
Selectors Level 4. The statement itself makes sense when read in the
context of the :scope proposal.
http://lists.w3.org/Archives/Public/www-archive/2008Jul/att-0025/Overview.html
But I suppose I could comment it out for now, until :scope is defined in
a real spec and the statement is actually needed.
Also, since the scope element stuff was deferred to another spec,
this spec remains somewhat ambiguous (at least to me) about exactly
what gets selected in the following case:
html
body
div class=bar
div id=foo
div class=baz/div
/div
/div
/body
/html
document.getElementById('foo').querySelector('.bar .baz')
This is covered in the spec by the statement:
Selectors are evaluated against a given element in the context the
entire DOM tree in which the element is located.
I believe the above querySelector call should return the baz div as
opposed to NULL, but it took me a few close readings of the spec to
decide on that. A clarifying example in the spec would be quite
helpful on this one.
Yeah, I suppose it's not too late to add a small example illustrating that.
I've made those changes in the current editor's draft. Though I'd
rather not make too many additional changes now as I don't want to hold
up publication. Any other issues like this can wait till after this
Last Call draft is published and can be fixed before it goes to CR.
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
Re: Call for Consensus - Selectors Last Call
Stewart Brodie wrote: 1) What is the scope element for - it's only mentioned in one sentence? That statement has now been commented out (see my previous mail [1]) 2) Is an empty string actually a valid selector? If not, then the whole null/undefined is an empty string discussion is irrelevant - it's simply a syntax error. Selectors defines what's considered valid or invalid, and an empty string is invalid. So having the spec say to treat null and undefined as empty strings is effectively an indirect way of saying it's a syntax error. 3) Does the matching algorithm work on based on the entire tree that contains the context node or just the sub-tree rooted at the context node? I think this is easiest fixed by adding an example like the one in the previous e-mail that I'm quoting and stating the expected result: Already added (see previous mail). [1] http://lists.w3.org/Archives/Public/public-webapps/2008OctDec/0216.html -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: Call for Consensus - Selectors Last Call
I support the publication as Last Call. On Oct 31, 2008, at 8:06 AM, Charles McCathieNevile wrote: Hi, Lachy thinks the latest editor's draft[1] is ready for Last Call, after responding to all the comments from last time (and removing the NSResolver). The disposition of comments[2] explains what happened to those comments. So this is a call for Consensus to publish the Editor's Draft [1] of the Selectors API spec as a Last Call. Please respond before Monday November 10. As always, silence is taken as assent but an explicit response is preferred. Opera supports publication of this draft as a Last Call. [1] http://dev.w3.org/2006/webapi/selectors-api/ [2] http://dev.w3.org/2006/webapi/selectors-api/disposition-of-comments.html 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: Call for Consensus - Selectors Last Call
Charles McCathieNevile: So this is a call for Consensus to publish the Editor's Draft [1] of the Selectors API spec as a Last Call. Please respond before Monday November 10. As always, silence is taken as assent but an explicit response is preferred. I’m in favour of publishing. A few comments though (since this consensus call prompted me to look at it), mostly editorial, before the LC period begins: * In the first sentence of section 6, I’d do /either/any of/, since there are more than two interfaces listed. * There’s a newer Web IDL WD available than the one referenced (with the new name) so it might be good to reference that. Then you can use [WEBIDL] as the reference link text instead. * In section 6, I don’t think it’s necessary to explicitly mention undefined, since it’s already handled by the annotation in the IDL. If you do want to include this in the prose, I think it needs to be qualified to say that this applies to an ECMAScript language binding of the interface. (null’s OK, since you can talk about null at the level of IDL values so it’s applicable to any language.) * s/an an asterisk/an asterisk/ in section 6.1. Thanks, Cameorn -- Cameron McCormack ≝ http://mcc.id.au/
Re: New Progress draft (1.25)...
On Fri, Oct 31, 2008 at 8:05 AM, Charles McCathieNevile [EMAIL PROTECTED] wrote: On Sat, 25 Oct 2008 09:08:56 +0200, Jonas Sicking [EMAIL PROTECTED] wrote: Garrett Smith wrote: On Fri, Oct 24, 2008 at 5:51 AM, Jonas Sicking [EMAIL PROTECTED] wrote: Garrett Smith wrote: I agree. Not sure if that is what you want to do before or after getting the load/error/abort event though? I should mention that I'm not particularly married to having things one way or another. But I think we should have reasons for choosing. Agree. Anyone who has another use case for loadend, please post up. I was also wondering why in your use case it made sense to fire loadend before load/error/abort? I.e. what would you be doing in those events such that you want the progress bar hidden at that point. Though I do agree that it makes sense to say i'm done before here's the data (or it failed). It seems to me that the order is not that significant - either you are trapping the specific end cases (I'm done / It failed), or you don't really care about them so you use the convenience loadend event, e.g. to remove your progress bar. I'm done is the loadend event and it failed is the error message from abort|error. Given that whichever comes first will fire whichever comes second, I think the symmetry is as good an argument as any for ordering, so I am inclined to leave what we have now. Garrett, do you think that is really a wrong decision (and if so do others agree we should change it back)? I've coded to requirements that specify the busy icon being hidden and a message being shown. In those cases, I wanted a 'done' event. It would be helpful to have input from HCI and U/X experts. What are the majority of cases, is it notify user of progress complete and display a message, or display a message, then notify the user of progress complete. Having loadend fire last is still better than not having it at all. In the cases where order is significant, then it's still possible to code around it. Cheers Chaals --
