- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Thu, 31 Dec 2009 06:47:02 -0600
- 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 automatically.) ~TJ
Received on Thursday, 31 December 2009 12:47:31 UTC