On Tue, Jul 7, 2009 at 2:07 AM, Gregory Maxwellgmaxwell@gmail.com wrote:
Of course, that could be done without switching the rest of the site to HTML5...
Well, not without breaking XHTML validity, and in that case what's the point of sticking with XHTML? I don't think we'll be serving an HTML 5 doctype for pages with <video>, and an XHTML 1 doctype otherwise.
take more traffic from clients doing range requests to generate the poster image
You should be able to use the "poster" attribute. Firefox doesn't support this until 3.6, though https://bugzilla.mozilla.org/show_bug.cgi?id=449156. (I *think* WebKit already supports it, at least on trunk, based on some quick searches of their Bugzilla; not sure since when.) For Firefox 3.5, you could add the poster image with JavaScript, which is still strictly better than the current situation. Probably it would be possible to provide the poster image using some simple CSS hacks, too.
I don't know what range requests you're referring to?
and potentially traffic from clients which decide to go ahead and fetch the whole video regardless of the user asking for it.
This is supposed to be controlled by the autobuffer attribute. Are you aware that any user agents will buffer the whole video even if this attribute isn't present? It would probably be sensible to have autobuffer set on the file page itself, but not when it's included in articles. (I'd hope browsers wouldn't request the *whole* thing even if autobuffer is set, only enough to be able to reliably play to the end if the user hits play.)
Of course, part of the whole point of the <video> element is that content authors are giving up control over implementation details to browser authors. If Firefox buffers video too aggressively . . . file a bug with them and fix it for everyone! :) A bare <video> tag will mean the user doesn't have to interact with site-specific custom apps -- which is the idea. Let them use the same native browser interface that they'll (hopefully) become accustomed to from all the other sites using <video>.
There is also still a bug in FF3.5 that where the built-in video controls do not work when JS is fully disabled. (Because the controls are written in JS themselves)
Well, that's unfortunate, but it hopefully won't affect 3.6. Surely it won't affect Chrome, or Safari with the appropriate codec installed. Even at worst, it won't be noticeably inferior to the current situation for these users, and there are other benefits (no need to load Cortado at all, no custom interface).