[whatwg] HTMLMediaElement: more issues and ambiguities

Thu Jul 3 01:35:35 PDT 2008

Today, another batch of HTMLMediaElement issues. Each issue begins with
a link, so skip other those which seem uninteresting.

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.

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

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

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.

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.

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.

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.

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.

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

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

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.

http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#volume

Just to reiterate the request that the default volume be 1.0.

OK, that's all folks!

-- 
Philip Jägenstedt
Opera Software