[whatwg] HTMLMediaElement: more issues and ambiguities

[Ian Hickson]

On Thu, 3 Jul 2008, Philip Jägenstedt wrote:
> 
> http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#poster
> 
> "If the specified resource is to be used, it must be fetched when the 
> element is created or when the poster attribute is set."
> 
> Typically images are only loaded if they are visible, but what policy 
> the user agent has here is not something the spec needs to be concerned 
> with. I suggest simply removing it.

It matters because if the base URL changes between when the URL is set and 
the URL is resolved, then you might get a different image.

However, nothing says how long you need take to "fetch" the image. So long 
as you resolve the URL immediately.

(Fetching will be defined in more detail eventually and will say this 
explicitly.)


> http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#adjusted
> 
> "If the video's pixel ratio override's is none, then the video's 
> intrinsic width is the width given by the resource itself. If the video 
> has a pixel ratio override other than none, then the intrinsic width of 
> the video is the width given by the resource itself, divided by the 
> pixel ratio given by the resource itself, multiplied by the video's 
> pixel ratio override."
> 
> This is a pixel ratio *override*, suggest changing it to:
> 
> "If the video's pixel ratio override's is none, then the video's 
> intrinsic width is the width given by the resource itself multiplied 
> by the pixel ratio given by the resource itself. If the video has a 
> pixel ratio override other than none, then the intrinsic width of the 
> video is the width given by the resource itself multiplied by the 
> video's pixel ratio override."

The idea is that if you set the override to a 1:2 ratio, then each pixel 
of video data will be rendered 1:2. So you first have to normalise the 
width, getting rid of the influence of the "official" pixel ratio. No?


> The use of the term "intrinsic" is rather confusing:
> 
> http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#pixelratio
> 
> "The [pixelratio] attribute value, if specified, must be a valid 
> floating point number giving the ratio of the correct rendered width of 
> each pixel to the actual width of each pixel in the image (i.e., the 
> multiple by which the video's intrinsic width is to be multiplied to 
> obtain the rendered width that gives the correct aspect ratio). "
> 
> Intrinsic isn't used to mean "native" but rather something with relation 
> to the "default" dimensions in layout and CSS. Or so it seems to me. 
> Changing this to "the multiple by which the video's *native* width is 
> to be multiplied to obtain the *intrinsic* width that gives the correct 
> aspect ratio" would do?
> 
> If I've not missed something, we then have:
> 
>  - native width/height, equivalent to "the width/height given by the
> resource itself"
>  - intrinsic width/height, the aspect-corrected width/height at which
> the video will be rendered unless subject to further width/height
> constraints (CSS or width/height attributes).
> 
> I find it counter-intuitive that native and intrinsic mean different
> things when talking about video, but perhaps that's just me.

This was confused, but I've tried to address it. I've removed the concept 
of a "native" dimension, it's all in terms of intrinsic dimensions now. 
Please let me know if the text is still confusing.

The changes are in r1853.


> http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#defaultplaybackrate
> http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#playbackrate
> 
> Here it is again, "intrinsic". Suggest using "native speed".

I don't understand why "native" is better than "intrinsic".


> http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#pick-a
> 
> Consider this example:
> 
> <video>
>   <source src="wont_use.ogg" media="unsupported" pixelratio="1.333">
>   <source src="standard.ogg" media="screen">
> </video>
> 
> In the current algorithm, the pixelratio is evaluated (step 5) before 
> verifying the suitability of the candidate (step 6). The result in that 
> "chosen resource's pixel ratio override" (it's just a variable) has 
> been given the value "1.333" when "standard.ogg" is chosen, which is 
> obviously not the intention.
> 
> Solution: Move step 5 into step 6, just before the jump. Perhaps step 1 
> could be removed too with some rewording in step 10.

I've just makde step 5 reset the variable to "none" if it doesn't 
otherwise set it. We need step 1 since it's used by the src="" attribute 
case, and putting it into step 6 would make a long step even longer.


> http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#load
> 
> "Any already-running instance of this algorithm for this element must be 
> aborted. If those method calls have not yet returned, they must finish 
> the step they are on, and then immediately return."
> 
> The intention is probably that algorithms running at step 11 and beyond 
> be stopped. However, what happens when the load() method is called from 
> the abort or emptied event handlers? The first invocation cannot return 
> before the second invocation returns, a deadlock condition. I suggest 
> that an INVALID_STATE_ERR exception be raised in the second call.

It wasn't my intention that step 1 be blocking. I've made this clearer.


> Also, I would like the loadstart event to be synchronous just like 
> abort/emptied. Currently, it isn't quite clear what the below does.
> 
> function handleEvent(e) {
>   // do something that takes a lot of time
>   alert("event handled");
> }
> m.addEventListener("loadstart", handleEvent, false);
> m.load();
> alert("load returned");
> 
> The order will be "event handled", "load returned" if loadstart is 
> synchronous, otherwise scheduling-dependent.

It was intended to be synchronous (which is why the event is fired before 
the method returns) but I guess I should be consistent and always say 
"synchronous". Fixed.


> http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#canplaythrough
> 
> A bit down there is a typo "leaded-first-frame" which should probably be 
> a link too.

Fixed.


> http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#play
>
> After play() and pause() there are 2 paragraphs and a note that I'm not 
> sure what they are trying to address. It seems that the intention is 
> that one can remove a media element from one document and insert into 
> another without it breaking, but there are other consequences too.
> 
> "Media elements must not stop playing just because all references to 
> them have been removed" can be taken to mean that media should keep 
> playing even when the user navigates away from the containing document, 
> which doesn't seem very nice as there would be no way to stop it.

Right, the next paragraph addresses this.


> "If the media element's ownerDocument stops being an active document, 
> then the playback will stop until the document is active again." Why? If 
> someone wants to listen to music in the background, why should we stop 
> them? It seems to me that this should be up to implementors to decide, 
> possibly stopping background media elements if they are consuming too 
> much resources, etc.

You are misunderstanding "active document". It has a very specific 
meaning. Follow the various hyperlinks from those two paragraphs. :-)

Let me know if this is still confusing.


> This note is a consequence of "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."
> 
> I suggest simply removing "its owner Document is an active document", 
> possibly adding that user agents may or may not stop media elements 
> which are playing the background (per the user setting, possibly).

This is the paragraph that prevents the video from playing when the user 
navigates away from the page. Background documents are still active if 
the user hasn't navigated away from them.


> http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#voidcallback
> 
> As discussed with Hixie on IRC, this is actually the WebIDL way of 
> describing a function with no parameters or return value, so a note that 
> user agents *shouldn't* accept objects with handleEvent methods would be 
> in order.

I'll address that in due course now that WebIDL has callback support.

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