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

On Tue, Jan 5, 2010 at 7:08 AM, Silvia Pfeiffer
<silviapfeiffer1@gmail.com> wrote:
> On Tue, Jan 5, 2010 at 7:43 PM, Scheppe, Kai-Dietrich
> <k.scheppe@telekom.de> wrote:
>> Hi,
>>
>>> What are the actual use-cases for author control over buffering here?
>>> The only reasons I can think of are
>>>
>>> 1) Improve user experience.
>>> 2) Conserve server bandwidth.
>>>
>>> For (1), is it likely that typical authors will ever be able
>>> to make a better guess on whether autobuffering is needed
>>> than implementers?
>>> Why would this be?  What information would authors have that
>>> the browser couldn't figure out just as well?  This is all
>>> keeping in mind that while browser heuristics will fail
>>> sometimes, so will author use of the autobuffer attribute.
>>
>> The question is not whether authors are likely to do something or not.
>> By not giving them the opportunity in the first place we will certainly keep them from learning.
>>
>> Furthermore, it is not the small time authors that drive usage of technology, but the big ones, who have a stake in doing it correctly and serve as examples to the others.
>> Everybody looks at how the "big guys" are doing it.
>>
>> As such please do not discount that people are capable of doing things correctly.
>
> I'd actually like to chip in here - I was rather offended by the
> remark that authors cannot be trusted. While there are many authors
> out there that really don't know what they are doing, there are many
> that do. Standards are not written for those that don't know what they
> are doing - those people don't care one way or another anyway. But we
> write these standard for those that know what they are doing to enable
> them to give good markup to the browser, which it turn enables the
> browsers to do the right thing.
>
> I don't think that the argument "there are bad Web authors out there"
> should ever be an acceptable argument against a perfectly valid
> feature: "Our authors are incapable, therefore we have to incapacitate
> them." It should, however, be an argument against enabling the
> specification of contradictory markup - such as both an autobuffer and
> a noautobuffer attribute. That's just asking for trouble.
>

I know this group hates +1, but sometimes it needs to be given.

+1

Silvia makes an extremely good point: the fact that some folks might
use something incorrectly is not justification for not providing the
capability at all. It's up to us to ensure that the capability is well
documented, and advocate for its correct use--not deny it to web
authors, because we can't be trusted.

> Regards,
> Silvia.
>
>

Shelley

Received on Tuesday, 5 January 2010 13:18:20 UTC