W3C home > Mailing lists > Public > public-html@w3.org > December 2009

Re: Public feedback on HTML5 video

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Thu, 31 Dec 2009 06:47:02 -0600
Message-ID: <dd0fbad0912310447h3e3ea117vb4c8b459c00c85d3@mail.gmail.com>
To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Cc: Anne van Kesteren <annevk@opera.com>, Philip J├Ągenstedt <philipj@opera.com>, "Edward O'Connor" <hober0@gmail.com>, Jeremy Keith <jeremy@adactio.com>, HTMLwg <public-html@w3.org>
On Thu, Dec 31, 2009 at 5:15 AM, Silvia Pfeiffer
<silviapfeiffer1@gmail.com> wrote:
>> Is it a
>> really common use case not to want any initialization at all for the video?
> I believe so. Every web page that has more than maybe 3 videos
> "embedded" - and that is video search results pages, video archive
> listings and similar things - will need to stop their videos from
> taking up unwanted bandwidth. This is a really common use - and also
> one that John Gruber's blog post mentioned.

It's really not what Gruber mentioned, though.  He, and the rest of
us, don't want a page with 3+ (or 50+) <video>s to start buffering all
of them.  That's obviously bad.  But grabbing a little bit of
information from each, to determine intrinsic ratios and duration?
That's both fine, and roughly on par with downloading an image.  We're
fine with the performance of 50+ images on a page, so why do we need
the ability to control <video> any more carefully?

>> Not having the element/link in the page does seem like a good solution to
>> that problem, to prevent plugins, search engines, etc. to take hold of it.
> But it will only work in js enabled browsers. For a common use case
> such as video search and video listings, this is quite something to
> ask, IMHO.

The replacement will only work when js is enabled.  It's trivial to
wrap the thumbnail in a link to a page displaying that single <video>,
and just turn off the link behavior with js.  Best of both worlds -
zero <video> information downloaded until the user indicates they want
to view it with a click (either triggering the link or the js) and
hopefully only a slight delay as the video initializes over having the
<video> in the page in the first place.

Of course, it's still extra effort, and is going to be slightly slower
to start the video.  As soon as Webkit fixes their bug, it's almost
certainly best for both the author and the user to just put the
<video>s directly in the markup and leave @autobuffer off.  Each video
will siphon only a minimum amount of bandwidth to establish valuable
meta information, and they'll already be set up for the user.

So I'll echo what ROC just said and promote us all just relaxing.
This'll take care of itself.  ^_^  (It may still be a good idea to
make it explicit in the spec that the lack of an @autobuffer attribute
indicates that the video may not be played and should not be buffered

Received on Thursday, 31 December 2009 12:47:31 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:55 UTC