RE: [html4all] from hixies log - Fire, a two-hour weekend, accessibility,and other rants

Lachlan Hunt wrote:
> 
> You have to consider the alternative situation.  Without an autoplay
> attribute, authors are going to resort to scripted techniques to
> achieve the same effect by invoking video.play() upon loading.  Now
> consider how much easier it is for user agents to provide preferences
> to override an autoplay attribute, compared with overriding the
> scripted alternatives. 

Interestingly enough, I was thinking about this very topic on the way to
work today.  One solution then is that the autoplay *must* be an attribute
that 'compliant UAs' can over-ride: a toggled attribute that is put in the
hands of the user (Tools >>> Preferences >>> Media >>> disable autostart -
checked).

It's not just users of screen readers who may wish to toggle their UA so
that video content (actually *any* audio based feed) won't autostart, there
are numerous instances when 'mainstream' consumers would want to invoke
this:  the classic case of a Dilbert cube farm being interrupted by one user
who hits a "non-work related site" that starts blasting music or other audio
is all-to-familiar to anyone who has ever worked in a cube farm.  As well,
I've noted that sites such as Ziff-Davis will have "flash" ads that are
mini-movies, and while they autostart, they do so in "silent" mode, the user
must toggle the audio track on (emergent cowpath).

So whether the attribute becomes 'autostart', or autostart:true/false is
moot - the spec must mandate that user agents allow individual users to
over-ride author declared state here.

"3.14.9.4. Loading the media resource:
All media elements have a begun flag, which must begin in the false state, a
loaded-first-frame flag, which must begin in the false state, and an
autoplaying flag, which must begin in the true state."
Addendum: The autoplaying flag must be configurable by the end user:
compliant UAs might ship with a default state of "active", but users must
have a clear and reasonable means of disabling this state.


> 
> So in both cases, it's better to endorse the lesser of 2 evils because
> any attempt to forbid it will arguably lead to a much worse situation.

Agreed, however, just like today's browsers ability to suppress popups (or
toggle to "Open in new tab") ultimate control must reside with the end user.

You want constructive?  Take this as being constructive.

JF

Received on Thursday, 6 September 2007 17:03:20 UTC