Re: [whatwg] When to stop video elements from playing
On Mon, 29 Oct 2007, Jonas Sicking wrote: I believe the best solution here is to say that step 5 should throw an exception. I.e. you can't start playing a media element whose .ownerDocument is not a displayed document. What do you think of what the spec says at the moment? Are you referring to When a media element is actively playing and its owner Document is an active document, its current playback position must increase monotonically at playbackRate units of media time per unit time of wall clock time? First of all, that'll mean that calling .play() on a in-non-active-document element will silently fail. It'd probably be better to throw an exception. It's also something that's easier to miss for an implementor. Might be a good idea to put it in the steps for play() and change the removed-from-document paragraph to say: When a media element is removed from a Document, or the .ownerDocument stops being an active document, the user agent must act as if the pause() method had been invoked. Throwing an exception means that you can't start a video without first checking if the document is visible, and pausing when the document is made not active means that when you return to the document the video won't be playing. Neither of these seems desireable. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] When to stop video elements from playing
On Mon, 29 Oct 2007, Jonas Sicking wrote: Scripts can actually still run fine even if you navigate away from a page. But there are definitely weird things happening (such as global scope being different from 'window'). This isn't the thread to discuss this though. I've saved your mail to the scripts pile for future examination. I believe the best solution here is to say that step 5 should throw an exception. I.e. you can't start playing a media element whose .ownerDocument is not a displayed document. What do you think of what the spec says at the moment? Are you referring to When a media element is actively playing and its owner Document is an active document, its current playback position must increase monotonically at playbackRate units of media time per unit time of wall clock time? Yes. First of all, that'll mean that calling .play() on a in-non-active-document element will silently fail. It'd probably be better to throw an exception. If it throws an exception, how do you switch it to the play mode? You might well want to do this, e.g. if it is possible the document in question will once against become an active document. It's also something that's easier to miss for an implementor. Might be a good idea to put it in the steps for play() and change the removed-from-document paragraph to say: When a media element is removed from a Document, or the .ownerDocument stops being an active document, the user agent must act as if the pause() method had been invoked. But that makes it possible to have the problem you mentioned, with elements that never stop playing. I've put a note in the text near the pause() method that points out the active document thing. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] When to stop video elements from playing
Ian Hickson wrote: I believe this can happen in a number of ways, the simplest being that Page A calls a function on Page B. But I suspect there are also events that can fire in Page B even after it has closed. Actually per spec, if I recall, you can't run script if you're not an active document. (To start with, your Window object won't have your properties any more, which makes things difficult if we allow script.) Scripts can actually still run fine even if you navigate away from a page. But there are definitely weird things happening (such as global scope being different from 'window'). This isn't the thread to discuss this though. I believe the best solution here is to say that step 5 should throw an exception. I.e. you can't start playing a media element whose .ownerDocument is not a displayed document. What do you think of what the spec says at the moment? Are you referring to When a media element is actively playing and its owner Document is an active document, its current playback position must increase monotonically at playbackRate units of media time per unit time of wall clock time? First of all, that'll mean that calling .play() on a in-non-active-document element will silently fail. It'd probably be better to throw an exception. It's also something that's easier to miss for an implementor. Might be a good idea to put it in the steps for play() and change the removed-from-document paragraph to say: When a media element is removed from a Document, or the .ownerDocument stops being an active document, the user agent must act as if the pause() method had been invoked. / Jonas
Re: [whatwg] When to stop video elements from playing
Ian Hickson wrote: First of all, that'll mean that calling .play() on a in-non-active-document element will silently fail. It'd probably be better to throw an exception. If it throws an exception, how do you switch it to the play mode? You might well want to do this, e.g. if it is possible the document in question will once against become an active document. It's also something that's easier to miss for an implementor. Might be a good idea to put it in the steps for play() and change the removed-from-document paragraph to say: When a media element is removed from a Document, or the .ownerDocument stops being an active document, the user agent must act as if the pause() method had been invoked. But that makes it possible to have the problem you mentioned, with elements that never stop playing. What I meant was to make play() throw if .ownerDocument isn't active, and make elements pause() when the .owernDocument goes inactive. In that case it shouldn't be possible to never stop playing. I agree that it might be desirable to put the video in play-mode without actually starting to play it, so the current text looks fine. / Jonas
Re: [whatwg] When to stop video elements from playing
On Fri, 19 Oct 2007, Robert O'Callahan wrote:
Suppose a script creates a video element, adds it to the document,
starts it playing, then removes the element from the document and drops
all references to it. When should the element stop playing?
I've made the spec say that it stops playing when you remove it from the
document. However, that doesn't really mean much, it can still play when
it's out of the document.
-- when all JS references to the element have been dropped (and garbage
collection runs)?
-- when the user leaves the page?
-- when the end of the stream is reached? (which could be never)
I've explicitly addressed all of these in the spec.
On Thu, 18 Oct 2007, Maciej Stachowiak wrote:
However, you'd probably want audio elements to be able to play outside
the document.
Indeed, that's an important use case.
On Fri, 19 Oct 2007, timeless wrote:
I can easily have a bookmarklet that goes through the dom tree and stops
(or stops and deletes) all audio elements. I can't have such a
bookmarklet for things that are only reachable via JS scope (and I don't
mean JS object graph, I mean function call chains, since that's the best
way to be evil, site's don't need to let people have access via object
properties).
Bookmarklets are effectively browser-specific and thus interoperability
isn't a concern for them. They can use UA-specific extensions if needed.
On Fri, 19 Oct 2007, timeless wrote:
On 10/19/07, Anne van Kesteren [EMAIL PROTECTED] wrote:
This doesn't seem like something a typical end user would do.
the how perhaps not, but i think the goal is.
If a user wants to mute all audio, a mute key on the keyboard or in the
UA's chrome seems like the more likely solution, both of which are
possible within the constraints of the spec.
On Sat, 20 Oct 2007, dev wrote:
As a user , I would really prefer that the no Sound comes from the
browser, unless and until I can see a play/pause button inside the page.
So if the element is removed the sound and/or the video should stop.
This is what the spec now requires.
On Fri, 19 Oct 2007, Robert O'Callahan wrote:
A related question is whether display:none audio and video elements
should produce sound.
Yes. The sound from audio and video elements isn't stylistic; it's
asynchronously played content, and thus not affected by CSS properties.
My current opinion is that audio and video elements should behave
like img and load/play whether or not they're in a document, but they
should only emit sound if they're in a document with a presentation and
are not in a display:none subtree. Then to play a sound you'd have to
insert the element into your document somewhere with size 0x0 (which
should be the default for audio).
But it's a rather tangled issue.
Having to insert audio elements in the tree to have them play seems
artificial, especially since they wouldn't play where you put them -- the
tree position would be basically meaningless. A typical use case is the:
var a = new Audio('fx.wav');
a.autoplay = true;
...or similar.
On Fri, 19 Oct 2007, Anne van Kesteren wrote:
I think you want to do:
var soundeffect = new Audio(sound.wav)
soundeffect.onload = function() { this.play() }
which is what was possible with the old Audio API (became audio) Opera
implemented.
Right, that too.
On Fri, 19 Oct 2007, Robert O'Callahan wrote:
When would the Opera stop playing that sound? When the user left the
page? Only when the sound finished?
Per spec, at the earliest of the two. (Though in the former case, if the
user returned to the page and the bfcache hadn't flushed the message away,
the sound would resume playing.)
On Fri, 19 Oct 2007, Jonas Sicking wrote:
No. The time at which garbage collection will reclaim an object is
unpredictable, so relying on garbage collection for behavior is a bad
idea.
Agreed.
If we let videos or audios play even when out of the document I
don't see how we could avoid this.
The spec requires audible elements not to be garbage collected.
Or do you mean by 'play' only move forward in their time-position, not
emit sound?
Sound emission.
What happens in opera is if you do:
myAudio = new Audio(foo.wav);
myAudio.onload = function () {
this.play();
myAudio = null;
}
When will the audio stop playing?
Per spec, the element will play through to the end (or until the browsing
context is navigated away).
On Fri, 19 Oct 2007, Jonas Sicking wrote:
Opps, forgot to answer this one. I strongly feel that both audio and
video should make sound for display:none elements. The CSS display
property should only affect the visual appearance of the node.
Additionally, it's more efficient for us, and simpler for the author, if
hidden-but-played audio/video elements don't create a frame and don't
affect layout.
Agreed.
On Fri, 19 Oct 2007, fantasai wrote:
A related question is whether display:none
Re: [whatwg] When to stop video elements from playing
A couple of comments: The spec currently doesn't say to set the autoplaying flag to false when an element is removed from the Document. I take it that will mean that the element will start playing if it's currently waiting for data? This seems undesirable to me for two reasons: A) I think nodes not in the document should only start playing when more explicitly asked to. B) It creates a race condition where the element _will_not_ play when if enough data had been downloaded at the point when the element was removed, but _will_ play if it was still waiting for data. Is there any reason we couldn't state the removing the element from the Document calls pause() on the element? I think that it is still currently possible that a currently playing element can get garbage collected. Alternatively, that it is possible to create elements that will never stop playing, even if the user navigates away. Consider the following scenario: 1) Page A opens a new window containing Page B 2) Page A creates a reference to Page B 3) Page B creates an audio element that doesn't live in its Document and sticks it in a global variable of its context. 4) Window containing Page B is closed. Page B does not go away since Page A is holding a reference to it. 5) Page B calls .play() on the audio 6) Page A drops reference to Page B 7) Garbage Collection runs 8) User leaves Page A 9) Garbage Collection runs The only step here that is slightly suspicious is step 5 since a closed-but-alive page is running script. I believe this can happen in a number of ways, the simplest being that Page A calls a function on Page B. But I suspect there are also events that can fire in Page B even after it has closed. The question is, when does the audio element stop playing? If it stops playing in step 7 we still have the situation that it can stop running at a seemingly random point in time, i.e. when GC runs. Step 6 isn't necessarily even needed since both Page A and Page B would get destroyed in step 9 anyway. If we say that the audio should not get garbage collected in step 7 since it is playing audio, at what point should it stop playing? There is no connection between the audio and Page A so step 6 and 8 won't be special in any way to the audio. I believe the best solution here is to say that step 5 should throw an exception. I.e. you can't start playing a media element whose .ownerDocument is not a displayed document. Other suggestions welcome. / Jonas
Re: [whatwg] When to stop video elements from playing
On Fri, 26 Oct 2007, Jonas Sicking wrote: A couple of comments: The spec currently doesn't say to set the autoplaying flag to false when an element is removed from the Document. I take it that will mean that the element will start playing if it's currently waiting for data? This seems undesirable to me for two reasons: A) I think nodes not in the document should only start playing when more explicitly asked to. B) It creates a race condition where the element _will_not_ play when if enough data had been downloaded at the point when the element was removed, but _will_ play if it was still waiting for data. Is there any reason we couldn't state the removing the element from the Document calls pause() on the element? Good point. Fixed. I think that it is still currently possible that a currently playing element can get garbage collected. Alternatively, that it is possible to create elements that will never stop playing, even if the user navigates away. Consider the following scenario: 1) Page A opens a new window containing Page B 2) Page A creates a reference to Page B 3) Page B creates an audio element that doesn't live in its Document and sticks it in a global variable of its context. 4) Window containing Page B is closed. Page B does not go away since Page A is holding a reference to it. 5) Page B calls .play() on the audio At this point nothing happens, because B isn't an active document, and playback only occurs (according to the spec) if the ownerDocument is an active document. The only step here that is slightly suspicious is step 5 since a closed-but-alive page is running script. Right, but the point would still hold if page A called .play(). I believe this can happen in a number of ways, the simplest being that Page A calls a function on Page B. But I suspect there are also events that can fire in Page B even after it has closed. Actually per spec, if I recall, you can't run script if you're not an active document. (To start with, your Window object won't have your properties any more, which makes things difficult if we allow script.) I believe the best solution here is to say that step 5 should throw an exception. I.e. you can't start playing a media element whose .ownerDocument is not a displayed document. What do you think of what the spec says at the moment? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] When to stop video elements from playing
On Wed, 24 Oct 2007 01:53:56 +0200, Jonas Sicking [EMAIL PROTECTED] wrote: fantasai wrote: Robert O'Callahan wrote: A related question is whether display:none audio and video elements should produce sound. No. display: none is defined to affect all media, and that certainly should not change for audio and video. I think this is different than screen readers not speaking display:none text. Both hiding layout frames and silencing screen readers only affect the 'rendering' of the contained text, it doesn't otherwise deactivate the contained display:none elements: What matters is how display: none is defined [1], and as fantasai mentioned display is media: all, with special processing to boot: This value causes an element to generate no boxes in the formatting structure (i.e., the element has no effect on layout). Descendant elements do not generate any boxes either; this behavior cannot be overridden by setting the 'display' property on the descendants. Please note that a display of 'none' does not create an invisible box; it creates no box at all. Other properties like 'visibility' are defined as visual [2] and wouldn't affect audio rendering. With the caveat that it is a working draft that hasn't been updated for a long time, the CSS3 Speech property 'voice-volume' [3] and voice-volume: silent can be seen as analogous to visibility: hidden. [1] http://www.w3.org/TR/CSS21/visuren.html#display-prop [2] http://www.w3.org/TR/CSS21/visufx.html#propdef-visibility [3] http://www.w3.org/TR/css3-speech/#voice-volume -- Jonny Axelsson, Core Technology, Opera Software AS
Re: [whatwg] When to stop video elements from playing
Jonny Axelsson wrote: On Wed, 24 Oct 2007 01:53:56 +0200, Jonas Sicking [EMAIL PROTECTED] wrote: fantasai wrote: Robert O'Callahan wrote: A related question is whether display:none audio and video elements should produce sound. No. display: none is defined to affect all media, and that certainly should not change for audio and video. I think this is different than screen readers not speaking display:none text. Both hiding layout frames and silencing screen readers only affect the 'rendering' of the contained text, it doesn't otherwise deactivate the contained display:none elements: What matters is how display: none is defined [1], and as fantasai mentioned display is media: all, with special processing to boot: This value causes an element to generate no boxes in the formatting structure (i.e., the element has no effect on layout). Descendant elements do not generate any boxes either; this behavior cannot be overridden by setting the 'display' property on the descendants. Please note that a display of 'none' does not create an invisible box; it creates no box at all. Yes, so I think that a screen reader should not say whatever it would normally say when hitting a video that is display:none. However I see that as very different from silencing the audio stream coming from the video. The audio stream in a video is not what the screen reader would normally say when encountering a video, so I don't think that neither the voice-volume nor the display property should affect it. Do you consider it against the CSS spec that display:none stylesheets still are applied to the document? Or should that simply mean that display:none stylesheets should not be rendered or spoken by a screen reader? / Jonas
Re: [whatwg] When to stop video elements from playing
timeless wrote: I'd rather be able to use user.css and not be forced to run or install GreaseMonkey. Personally, I object to being required to use GreaseMonkey. MicroB doesn't ship with it (although as it happens, someone ported it). From a security standpoint, it's scary. As stated previously in this thread. I think disabling portions of a page should be done using internal mechanisms to the UA. So for example the UA could add a volume control to each browser window/tab that controls the volume of all things on that page making sound. Including audio, video and object. I don't think making everything doable using CSS is an appropriate solution. / Jonas
Re: [whatwg] When to stop video elements from playing
On Fri, 2007-10-19 at 20:46 -0400, fantasai wrote: Robert O'Callahan wrote: A related question is whether display:none audio and video elements should produce sound. No. display: none is defined to affect all media, and that certainly should not change for audio and video. Well, the current draft for CSS3 Speech Module implies that display: none; silences elements: http://www.w3.org/TR/css3-speech/#speak But the draft text for display itself continues to speak only of layout boxes: http://www.w3.org/TR/css3-box/#display And nowhere does the Basic Box Module draft discuss how such boxes are relevant to the aural or braille media types. It would be worth improving the drafts to be clearer on these points. If display is now to apply to audio, that is a change from the CSS2 era where the speak property affected spoken presentation and display seemingly affected only visual presentation: http://www.w3.org/TR/REC-CSS2/aural.html#speaking-props and where the failure of screen-reader/browser setups to vocalize elements set as a display: none; has popularly been regarded as a bug: http://css-discuss.incutio.com/?page=ScreenreaderVisibility -- Benjamin Hawkes-Lewis
Re: [whatwg] When to stop video elements from playing
It seems audio should be regulated by the attribute 'sound-volume' valued as a portion of the system sound volume level. Too bad CSS does not define it (unverified; I cannot look it up because whatwg.org is not responding:(145) Connection timed out). Cheers Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jonas Sicking Sent: Saturday, October 20, 2007 12:13 AM To: [EMAIL PROTECTED] Cc: WHATWG; Geoffrey Garen Subject: Re: [whatwg] When to stop video elements from playing Robert O'Callahan wrote: A related question is whether display:none audio and video elements should produce sound. Opps, forgot to answer this one. I strongly feel that both audio and video should make sound for display:none elements. The CSS display property should only affect the visual appearance of the node. Additionally, it's more efficient for us, and simpler for the author, if hidden-but-played audio/video elements don't create a frame and don't affect layout. / Jonas
Re: [whatwg] When to stop video elements from playing
The primary purpose of the display attribute is to regulate layout. That an element with no display is not visible is only a side effect. As long as there is no public standard for sound layout (the composers' and arrangers' know-how has not permeated to the Web yet and the acronym AUI is not commonly recognized), applying the display attribute to sound seems to be an unmotivated extrapolation. Best regards, Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of fantasai Sent: Saturday, October 20, 2007 2:46 AM To: [EMAIL PROTECTED] Cc: WHATWG Subject: Re: [whatwg] When to stop video elements from playing Robert O'Callahan wrote: A related question is whether display:none audio and video elements should produce sound. No. display: none is defined to affect all media, and that certainly should not change for audio and video. ~fantasai
Re: [whatwg] When to stop video elements from playing
I have not got the original Mr. Cox's suggestion so I can reply only indirectly. 1. CSS does not have elements, it defines attributes. 2. active: none is language abuse, it should be playback: none or active: disabled. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jonas Sicking Sent: Saturday, October 20, 2007 2:38 AM To: James Cox; whatwg Subject: Re: [whatwg] When to stop video elements from playing James Cox wrote: On 20 Oct 2007, at 00:31, Robert O'Callahan wrote: After some discussion on IRC, I think Jonas, Hixie and I agreed that we're OK with the following approach: -- sound is produced for display:none elements and elements not in the DOM what about people hiding ads or other elements via greasemonkey scripts (and so on) - using display:none hacks to remove from visibility? If naming is an issue, how about a new css element of active:none; which prevents any video/sound/display playing.
Re: [whatwg] When to stop video elements from playing
And the user probably will not visit the page ever again, just as a page
with bgsound. But that is up to the designer developer of course.
Sorry for wasting your time, I just could not resist.
Chris
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Robert O'Callahan
Sent: Saturday, October 20, 2007 1:32 AM
To: Jonas Sicking
Cc: Maciej Stachowiak; whatwg
Subject: Re: [whatwg] When to stop video elements from playing
After some discussion on IRC, I think Jonas, Hixie and I agreed that we're
OK with the following approach:
-- sound is produced for display:none elements and elements not in the DOM
-- removing an element from the DOM automatically calls stop() on that
element
-- tearing down the owner document always stops the element playing (so
navigating away from the page always stops sound)
Therefore
myAudio = new Audio(foo.wav);
myAudio.onload = function () {
this.play();
myAudio = null;
}
will work, and will play until the sound ends or the user leaves the page.
Rob
Re: [whatwg] When to stop video elements from playing
On 10/19/07, Anne van Kesteren [EMAIL PROTECTED] wrote: This doesn't seem like something a typical end user would do. the how perhaps not, but i think the goal is. Anyway, if you want to do it through script maybe mute function/property/something mute/stop/pause/disable that affects the top-level browsing context and children, if any, would be better, as that could take care of other means of embedding sound as well, such as embed, video, object, and iframe.
Re: [whatwg] When to stop video elements from playing
Robert O'Callahan wrote: A related question is whether display:none audio and video elements should produce sound. Opps, forgot to answer this one. I strongly feel that both audio and video should make sound for display:none elements. The CSS display property should only affect the visual appearance of the node. Additionally, it's more efficient for us, and simpler for the author, if hidden-but-played audio/video elements don't create a frame and don't affect layout. / Jonas
Re: [whatwg] When to stop video elements from playing
On Oct 20, 2007 1:46 PM, fantasai [EMAIL PROTECTED] wrote: Robert O'Callahan wrote: A related question is whether display:none audio and video elements should produce sound. No. display: none is defined to affect all media, and that certainly should not change for audio and video. I was sympathetic to that, but it may not compatible with playing elements that aren't in the document. And Jonas was arguing that it's lower overhead to not create a presentation for audio elements, although I think that's a very minor issue. I don't recall who else was pushing audibility of display:none elements. Rob -- Two men owed money to a certain moneylender. One owed him five hundred denarii, and the other fifty. Neither of them had the money to pay him back, so he canceled the debts of both. Now which of them will love him more? Simon replied, I suppose the one who had the bigger debt canceled. You have judged correctly, Jesus said. [Luke 7:41-43]
Re: [whatwg] When to stop video elements from playing
Hey, As a user , I would really prefer that the no Sound comes from the browser, unless and until I can see a play/pause button inside the page. So if the element is removed the sound and/or the video should stop. my 2c. regards dev
Re: [whatwg] When to stop video elements from playing
On 10/19/07, Anne van Kesteren [EMAIL PROTECTED] wrote:
For that you need something in the browser UI. There's a large, maybe
infinite, number of ways to make audio not visible even if it's within
the DOM tree. For instance:
audio { position:absolute; left:-1000px }
I can easily have a bookmarklet that goes through the dom tree and
stops (or stops and deletes) all audio elements. I can't have such a
bookmarklet for things that are only reachable via JS scope (and I
don't mean JS object graph, I mean function call chains, since that's
the best way to be evil, site's don't need to let people have access
via object properties).
Re: [whatwg] When to stop video elements from playing
On Oct 19, 2007 9:03 PM, Anne van Kesteren [EMAIL PROTECTED] wrote:
var soundeffect = new Audio(sound.wav)
soundeffect.onload = function() { this.play() }
which is what was possible with the old Audio API (became audio) Opera
implemented.
When would the Opera stop playing that sound? When the user left the page?
Only when the sound finished?
Rob
--
Two men owed money to a certain moneylender. One owed him five hundred
denarii, and the other fifty. Neither of them had the money to pay him back,
so he canceled the debts of both. Now which of them will love him more?
Simon replied, I suppose the one who had the bigger debt canceled. You
have judged correctly, Jesus said. [Luke 7:41-43]
Re: [whatwg] When to stop video elements from playing
On Oct 18, 2007, at 3:55 PM, Geoffrey Garen wrote: Suppose a script creates a video element, adds it to the document, starts it playing, then removes the element from the document and drops all references to it. When should the element stop playing? -- when the element leaves the document? Probably. Since you can't see the video any more, it would be really weird to hear audio from it, or waste computer resources on a mute and invisible video. Moreover, there's a lot of precedent for DOM elements not loading when they're not in the document. This is true of iframe, script, img, etc. However, you'd probably want audio elements to be able to play outside the document. Regards, Maciej
Re: [whatwg] When to stop video elements from playing
On Oct 19, 2007 11:55 AM, Geoffrey Garen [EMAIL PROTECTED] wrote: Suppose a script creates a video element, adds it to the document, starts it playing, then removes the element from the document and drops all references to it. When should the element stop playing? -- when the element leaves the document? Probably. Since you can't see the video any more, it would be really weird to hear audio from it, or waste computer resources on a mute and invisible video. Moreover, there's a lot of precedent for DOM elements not loading when they're not in the document. This is true of iframe, script, img, etc. It's not true of img. Javascript image preloading tricks rely on it. And as Maciej mentioned, it would be useful to be able to play audio outside the document, and to be consistent, video's behaviour should match. -- when all JS references to the element have been dropped (and garbage collection runs)? No. The time at which garbage collection will reclaim an object is unpredictable, so relying on garbage collection for behavior is a bad idea. Agreed. -- when the user leaves the page? Certainly. But you might want to stop the video sooner. Agreed. -- when the end of the stream is reached? (which could be never) Certainly. (How can you play past the end of the stream?) But you might want to stop the video sooner. Agreed. A related question is whether display:none audio and video elements should produce sound. My current opinion is that audio and video elements should behave like img and load/play whether or not they're in a document, but they should only emit sound if they're in a document with a presentation and are not in a display:none subtree. Then to play a sound you'd have to insert the element into your document somewhere with size 0x0 (which should be the default for audio). But it's a rather tangled issue. Rob -- Two men owed money to a certain moneylender. One owed him five hundred denarii, and the other fifty. Neither of them had the money to pay him back, so he canceled the debts of both. Now which of them will love him more? Simon replied, I suppose the one who had the bigger debt canceled. You have judged correctly, Jesus said. [Luke 7:41-43]
