On Tue, Jul 7, 2009 at 2:07 AM, Gregory Maxwell<gmaxwell(a)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).