Re: Should <video> buffer control be tri-state?

On Sat, Jan 2, 2010 at 9:42 PM, Maciej Stachowiak <mjs@apple.com> wrote:
> But right now there is no way to distinguish case (C) from case (A). So when
> autobuffer is omitted, browsers are faced with the choice of either never
> buffering, even if the omission is solely through lack of awareness, or
> applying heuristics even when the page author explicitly does not want
> buffering.

But authors don't just leave off attributes they don't know about,
they also add attributes they don't understand, copy-pasted from some
different context.  While a lot of authors will inadvertently leave
out autobuffer, some will inadvertently include it, too (and that's
much harder for users to notice).  Browsers can't rely on any markup
being correct when its effect is so subtle.

With a declarative tri-state control, I'd expect a situation something like:

* Well-written sites will mostly force autobuffering one way or
another, unless browsers develop excellent heuristics.  Authors assume
they know better than browsers.  Thus these sites will use the third
state rarely if ever.
* Poorly-written sites will copy from tutorials and other sites and
get a random value for autobuffer.  What would be best for these sites
is having no markup-based control here are all, or only weak
markup-based control, so browsers can do the right thing regardless.

My conclusion is that authors should be given limited control over
autobuffering from markup -- the autobuffer attribute should be a weak
hint.  Markup features tend to be copy-pasted, and most authors won't
spot subtle distinctions like whether the video is autobuffered.

Now, if authors really really want to force autobuffering off no
matter what, they can already do that through script hacks.  If this
happens a lot, even after existing WebKit is long retired, that will
be a clue that authors really want better autobuffering control.  In
the meantime, I think we shouldn't add an easier way to force
autobuffering off no matter what, because many authors will
accidentally misuse it.

The long-term goal should be that authors don't have to worry about
this, IMO, any more than they have to worry about explicitly telling
browsers whether to fetch images in stylesheets before they're used.

On Sun, Jan 3, 2010 at 1:47 AM, Robert O'Callahan <robert@ocallahan.org> wrote:
> The performance effect is very noticeable, and if your controls UI shows the
> buffer state, it's quite obvious what's going on.

The performance effect will typically be nonexistent when you're
testing, because you're probably reloading the same page with the same
video repeatedly as you make changes.  The video will thus remain
buffered no matter what.  Also, most developers just try to get things
working, and are going to be tweaking the layout and so on without
paying attention to performance.

So you'd have to wait for user complaints.  In practice, only a tiny
fraction of users complain about even serious problems with sites.  So
even quite large sites would wind up with incorrect video buffering if
any kind of hard control were made available from markup.

On Sun, Jan 3, 2010 at 6:37 AM, Philip Jägenstedt <philipj@opera.com> wrote:
> I agree with adding tri-state behavior in some form, although the details
> are still unclear. We must agree that turning buffering off means not even
> touching the network . . .
>
> Since this will cause us to remain at
> HAVE_NOTHING, authors must be very aware that duration and dimensions will
> not be available.

I don't see why anyone would possibly want this.  Browsers should
*always* fetch duration and dimensions.  The cost should be on par
with loading an extra image.

Received on Sunday, 3 January 2010 20:43:56 UTC