Spec ambiguity - <video> with a poster image but without preload="none"
Zack Weinberg
<video poster="..." width="x" height="y" controls>
<source src="...">
</video>
Firefox and Chrome display the specified poster image until the user
clicks the play button, regardless of whether the video itself is
available. IE9 prefers to display the first frame of the video once it
has the first frame of the video. The upshot is that if you want to be
sure the poster image shows in all browsers, you have to say
preload="none", which of course means you don't get any preloading.
Microsoft says that this behavior is by design and HTML5-compliant:
quoting IE Feedback Item 658399 (I am not aware of a public URL for
that, say sorry):
> [...] If you do not specify preload="none", IE will optimistically
> download the video. As soon as a video frame is available, it will
> display it instead of the poster image. This is in compliance with
> the HTML5 spec, which states:
> > [...] When a video element is paused and the current playback
> > position is the first frame of video, the element represents
> > either the frame of video corresponding to the current playback
> > position or the poster frame, *at the discretion of the user agent*.
(emphasis mine)
There is another paragraph in
http://dev.w3.org/html5/spec/video.html#video immediately after that
(not quoted by Microsoft - it may have been added recently) which offers
some guidance about appropriate behavior, but does not address this
specific case and is non-normative.
It seems to me that IE is complaint with the letter of the spec, but the
FF/Chrome behavior is preferable, since the first frame of the video may
not be at all representative of the video overall. (In my informant's
case, the video began with a fade-in so the first frame was solid
black.) Before I go trying to get HTML5 adjusted, though, I thought I
should run it by a more familiar audience. What do you think?
zw
Chris Pearce
behaviour is preferable. Best to take this up with WHATWG/public-html
mailing lists.
Chris P.
> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
Ian Hickson
>
> Microsoft says that this behavior is by design and HTML5-compliant: quoting IE
> Feedback Item 658399 (I am not aware of a public URL for that, say sorry):
>
> > [...] If you do not specify preload="none", IE will optimistically
> > download the video. As soon as a video frame is available, it will
> > display it instead of the poster image. This is in compliance with
> > the HTML5 spec, which states:
> > > [...] When a video element is paused and the current playback
> > > position is the first frame of video, the element represents
> > > either the frame of video corresponding to the current playback
> > > position or the poster frame, *at the discretion of the user agent*.
> (emphasis mine)
On Fri, 26 Aug 2011, Chris Pearce wrote:
>
> IE's behaviour is compliant with the spec, so is ours. I think our
> behaviour is preferable. Best to take this up with WHATWG/public-html
> mailing lists.
This changed a while back. The spec now says:
# When a video element is paused and the current playback position is the
# first frame of video, the element represents the poster frame, unless a
# frame of video has already been shown, in which case the element
# represents the frame of video corresponding to the current playback
# position.
IE is no longer strictly conforming here. (At least, not if they want to
claim to be a user agent that "supports the suggested default rendering",
which requires that the rendering match what the element represents, which
is what the quote above defines.)
--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Zack Weinberg
> On Thu, 25 Aug 2011, Zack Weinberg wrote:
>>>> [...] When a video element is paused and the current playback
>>>> position is the first frame of video, the element represents
>>>> either the frame of video corresponding to the current playback
>>>> position or the poster frame, *at the discretion of the user agent*.
>> (emphasis mine)
>
This is good to hear; unfortunately, I suspect if I / my informant
respond to the IE feedback request with a pointer to the WHATWG revision
they're going to tell me to go away until the W3C picks up the change.
Does anyone have a better idea?
> The spec now says:
>
> # When a video element is paused and the current playback position is the
> # first frame of video, the element represents the poster frame, unless a
> # frame of video has already been shown, in which case the element
> # represents the frame of video corresponding to the current playback
> # position.
It seems to me that this text could still be hair-split to permit IE's
behavior: the loophole is "unless a frame of video has already been
shown." I don't see anything in this vicinity that requires the
user-agent to not "show a frame of video" until the element ceases to be
paused (I could have missed it, but I looked pretty hard).
zw
Ian Hickson
> On 2011-08-25 5:57 PM, Ian Hickson wrote:
> > On Thu, 25 Aug 2011, Zack Weinberg wrote:
> > > > > [...] When a video element is paused and the current playback
> > > > > position is the first frame of video, the element represents
> > > > > either the frame of video corresponding to the current playback
> > > > > position or the poster frame, *at the discretion of the user agent*.
> > > (emphasis mine)
> >
> > This changed a while back.
>
> This is good to hear; unfortunately, I suspect if I / my informant
> respond to the IE feedback request with a pointer to the WHATWG revision
> they're going to tell me to go away until the W3C picks up the change.
> Does anyone have a better idea?
The WHATWG and W3C specs are identical.
> > The spec now says:
> >
> > # When a video element is paused and the current playback position is the
> > # first frame of video, the element represents the poster frame, unless a
> > # frame of video has already been shown, in which case the element
> > # represents the frame of video corresponding to the current playback
> > # position.
>
> It seems to me that this text could still be hair-split to permit IE's
> behavior: the loophole is "unless a frame of video has already been
> shown." I don't see anything in this vicinity that requires the
> user-agent to not "show a frame of video" until the element ceases to be
> paused (I could have missed it, but I looked pretty hard).
If the element is paused, and the video hasn't seeked, then the element
represents the poster frame unless a frame of video has already been
shown. Since that is the state when the video loads, and remains that
state until either the video is unpaused or seeked, how can anything else
be shown?
I don't understand how you would have another fram of video shown.
Which is to say, the sentence quoted above is the sentence that requires
that the user agent not show a frame of video until the element ceases to
be paused (or is seeked).
Ian Hickson
> >>
> >> This is good to hear; unfortunately, I suspect if I / my informant
> >> respond to the IE feedback request with a pointer to the WHATWG revision
> >> they're going to tell me to go away until the W3C picks up the change.
> >> Does anyone have a better idea?
> >
>
> text at http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html
That URL is stale. You want:
http://dev.w3.org/html5/spec/the-iframe-element.html#the-video-element
I don't know what the video.html file is. Probably some old version. The
W3C doesn't do a particularly good job of preventing stale versions from
existing (in fact they go out of their way to archive stale versions at
formal-looking URLs, but that's another story).
(In fact, looking at it more closely, the video.html file looks _really_
old, at least 3 months out of date.)
> >> I don't see anything in this vicinity that requires the user-agent to
> >> not "show a frame of video" until the element ceases to be paused (I
> >> could have missed it, but I looked pretty hard).
> >
> > If the element is paused, and the video hasn't seeked, then the
> > element represents the poster frame unless a frame of video has
> > already been shown. Since that is the state when the video loads, and
> > remains that state until either the video is unpaused or seeked, how
> > can anything else be shown?
>
> I don't have any confidence that there isn't wording elsewhere in this
> tangle of prose that says that you ought to "show" the first frame of
> video as soon as it becomes available, and doesn't pay attention to the
> possible existence of a poster frame.
There isn't. The text we are talking about (specifically, the paragraph in
question and the 7 paragraphs following it) is the only text that talks
about what the video element represents.
> If you have that confidence I will take your word for it, but I would
> still prefer that the ambiguity be removed from this paragraph
I don't really understand what's ambiguous here.
> (by using, for instance, the phrasing "unless the video element has
> previously been _potentially playing_" instead).
If the user seeked to another frame then seeked back to the first frame,
it should show the first frame, not the poster frame, even though it has
never been potentially playing.
L. David Baron
> On Thu, 25 Aug 2011, Zack Weinberg wrote:
> >
> > The text at http://dev.w3.org/html5/spec/video.html does not match the
> > text at http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html
>
> That URL is stale. You want:
>
> http://dev.w3.org/html5/spec/the-iframe-element.html#the-video-element
>
> I don't know what the video.html file is. Probably some old version. The
> W3C doesn't do a particularly good job of preventing stale versions from
> existing (in fact they go out of their way to archive stale versions at
> formal-looking URLs, but that's another story).
>
> (In fact, looking at it more closely, the video.html file looks _really_
> old, at least 3 months out of date.)
Filed http://www.w3.org/Bugs/Public/show_bug.cgi?id=13918 .
-David
--
𝄞 L. David Baron http://dbaron.org/ 𝄂
𝄢 Mozilla Corporation http://www.mozilla.com/ 𝄂
Zack Weinberg
>> respond to the IE feedback request with a pointer to the WHATWG revision
>> they're going to tell me to go away until the W3C picks up the change.
>> Does anyone have a better idea?
>
The text at http://dev.w3.org/html5/spec/video.html does not match the
text at http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html
.
>> I don't see anything in this vicinity that requires the
>> user-agent to not "show a frame of video" until the element ceases to be
>> paused (I could have missed it, but I looked pretty hard).
>
> If the element is paused, and the video hasn't seeked, then the element
> represents the poster frame unless a frame of video has already been
> shown. Since that is the state when the video loads, and remains that
> state until either the video is unpaused or seeked, how can anything else
> be shown?
I don't have any confidence that there isn't wording elsewhere in this
tangle of prose that says that you ought to "show" the first frame of
video as soon as it becomes available, and doesn't pay attention to
the possible existence of a poster frame. If you have that confidence
I will take your word for it, but I would still prefer that the
ambiguity be removed from this paragraph (by using, for instance, the
phrasing "unless the video element has previously been _potentially
playing_" instead).
zw
Zack Weinberg
> On Thu, 25 Aug 2011, Zack Weinberg wrote:
>>
>> The text at http://dev.w3.org/html5/spec/video.html does not match the
>> text at http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html
>
> That URL is stale. You want:
>
> http://dev.w3.org/html5/spec/the-iframe-element.html#the-video-element
>
> I don't know what the video.html file is. Probably some old version.
That was the document cited by the person at Microsoft who responded to
my informant's bug report. They have pointed Microsoft at the current
document now, and we'll see how that goes.
> (In fact, looking at it more closely, the video.html file looks _really_
> old, at least 3 months out of date.)
Good to know.
>> I don't have any confidence that there isn't wording elsewhere in this
>> tangle of prose that says that you ought to "show" the first frame of
>> video as soon as it becomes available, and doesn't pay attention to the
>> possible existence of a poster frame.
>
> There isn't. The text we are talking about (specifically, the paragraph in
> question and the 7 paragraphs following it) is the only text that talks
> about what the video element represents.
Ok.
>> If you have that confidence I will take your word for it, but I would
>> still prefer that the ambiguity be removed from this paragraph
>
> I don't really understand what's ambiguous here.
"has previously been shown" is the ambiguity, to my mind. It does not
exclude the possibility of a frame of video being "shown" as a
side-effect of the video being downloaded (rather than as a direct
consequence of user interaction with the video, or because the video was
set to autoplay).
>> (by using, for instance, the phrasing "unless the video element has
>> previously been _potentially playing_" instead).
>
> If the user seeked to another frame then seeked back to the first frame,
> it should show the first frame, not the poster frame, even though it has
> never been potentially playing.
I thought "potentially playing" covered that case. This section has a
bad case of circular and/or tautological definitions and opaque prose,
which leave me not really understanding it.
zw
Ian Hickson
> > >
> > > If you have that confidence I will take your word for it, but I
> > > would still prefer that the ambiguity be removed from this paragraph
> >
> > I don't really understand what's ambiguous here.
>
> "has previously been shown" is the ambiguity, to my mind. It does not
> exclude the possibility of a frame of video being "shown" as a
> side-effect of the video being downloaded (rather than as a direct
> consequence of user interaction with the video, or because the video was
> set to autoplay).
Could you elaborate on this? How would downloading a file cause it to be
rendered?
> > > (by using, for instance, the phrasing "unless the video element has
> > > previously been _potentially playing_" instead).
> >
> > If the user seeked to another frame then seeked back to the first
> > frame, it should show the first frame, not the poster frame, even
> > though it has never been potentially playing.
>
> I thought "potentially playing" covered that case. This section has a
> bad case of circular and/or tautological definitions and opaque prose,
> which leave me not really understanding it.
It's not circular or tautological, as far as I can tell, but I agree that
it is a bit complicated. Unfortunately, I'm not really sure how to improve
it. The situation just is complicated. If you have any suggestions I'd be
happy to entertain them.
Zack Weinberg
>> "has previously been shown" is the ambiguity, to my mind. It does not
>> exclude the possibility of a frame of video being "shown" as a
>> side-effect of the video being downloaded (rather than as a direct
>> consequence of user interaction with the video, or because the video was
>> set to autoplay).
>
> Could you elaborate on this? How would downloading a file cause it to be
> rendered?
I don't know any way it can, but I don't trust it to be impossible,
either. That's the whole problem here. You wrote the text and you have
confidence that the spec (as a whole) is worded to prohibit a frame of
video being "shown" except under the intended circumstances. I *don't*
have that confidence, because I don't understand the text well enough to
be sure it actually captures the intent.
(I'm confident that we are in agreement about the *intent* of the spec,
for the record.)
I'll see if I can find time to reread the whole section and propose a
comprehensive set of clarifications, but no promises.
zw