- From: Scheppe, Kai-Dietrich <k.scheppe@telekom.de>
- Date: Mon, 28 Dec 2009 13:09:57 +0100
- To: "Aryeh Gregor" <Simetrical+w3c@gmail.com>
- Cc: "HTMLwg" <public-html@w3.org>
Hi Aryeh, I understand your points, even though I have different opinions on some of them :-) implicit vs. explicit --------------------- However, please keep in mind that I was primarily making a point of implicit vs. explicit instructions. If I tell the browser to do something, explicitly, then I expect precicely that to happen. If however I say nothing, leaving it up to the browser to decide, introduces ambiguity. As such I think it would be good to define what it means, should an author remain silent on a given choice. buffering and bandwidth ----------------------- As for buffering I agree that it would be wasteful to buffer everything, if it is not used. Arguing in extremes may seem easy and clear, but is equivalent of looking only the tails of a bell curve. The majority of cases usually lies somewhere in between and tends to represent the more difficult path :-) Thus I find it preferable to enable the author to decide which video ought to be buffered and which not. I especially mention that, and also the issue of bandwidth, for the cases you refer to - mobile users and developing countries. It is the authors who know what's best for their audience, within their given context. In the end, however, it is up to the user to decide if they like the content or not. If authors make the wrong choices, users will vote with a click :-) As such, enabling authors by giving choices and producing predictable results is, to me, preferable to not doing so. -- Kai > -----Original Message----- > From: Aryeh Gregor [mailto:Simetrical+w3c@gmail.com] > Sent: Monday, December 28, 2009 12:05 PM > To: Scheppe, Kai-Dietrich > Cc: HTMLwg > Subject: Re: Public feedback on HTML5 video > > On Mon, Dec 28, 2009 at 5:15 AM, Scheppe, Kai-Dietrich > <k.scheppe@telekom.de> wrote: > > If it is left up to the browser to make an implicit decision, the > > outcome is not predictable across browsers, based on implementation. > > This is true, but there are downsides to specifying every detail. > Browser vendors are much fewer, and more professional and > knowledgeable, than content authors. Five major browser > vendors can assess usability and user feedback (not to > mention overall health of the web) much better than millions > of scattered content authors. > There are many cases where authors unknowingly do something > that considerably degrades user experience, and browsers > should be allowed to compete to provide a better user > experience overall in these cases. > The spec deliberately avoids exposing features to authors > that are likely to get misused. > > Note that user interests might not always align with author interests > -- for instance, browsers allow easy downloading of <video> > contents, which many authors won't want. Likewise, even if > downloading lots of content in the background might make > *your* site seem snappier, it also might take away bandwidth > from other things the user is doing, resulting in an overall > poorer user experience that the user won't think to blame on > your site. Probably he'll blame it on the browser, in fact. > > > - buffering is a usability issue. If something is displayed, > > buffering ought to be used because it aids in smooth display > > Not if the user probably won't actually click it. Not all > sites that include videos are like YouTube, where the video > is the whole point of the page. A page might contain a bunch > of videos, and they shouldn't all be buffered when the user > will probably view only one or two of them at most. That's > wasteful. Should every single video on this page be buffered > automatically by the client? > > http://commons.wikimedia.org/wiki/Category:Videos > > Or how about a forum thread where people are exchanging > embedded YouTube videos? I'm pretty sure YouTube doesn't > buffer in this case. > > > - bandwidth issues are not so big of an issue anymore. While it is > > important not to waste bandwidth, in the world of flatrates and > > broadband, usability is more of an issue. > > 1) This is true only to a point. Buffering all 200 of the > videos on the page I linked to above would be crazy even on broadband. > > 2) This is not true in the whole world. Just because your > website serves primarily broadband users does not mean that > all websites do. > Remember that a lot of people browse using cell phones, for > instance, never mind people living in poor countries. > > > - whether a poster frame is loaded or not is a design issue > and should > > be up to author, including the choice which frame to show > > Authors can control this by using the poster attribute. >
Received on Monday, 28 December 2009 12:10:33 UTC