[whatwg] A new attribute for <video> and low-power devices

[Ian Hickson]

On Mon, 18 May 2009, Benjamin M. Schwartz wrote:
>
> As I have mentioned earlier, there are some devices that will be unable 
> to render <video> faithfully inline, due to the limitations of hardware 
> video accelerators.  However, it occurs to me that there are two 
> essentially different uses for <video>
> 
> 1. Important content for the webpage.  An example would be the central 
> video on a web page whose purpose is to allow users to view that video. 
> This is currently done principally using Adobe Flash and (to a lesser 
> extent) <object> tags.
> 
> 2. Incidental animations.  Examples include decorative elements in a web 
> page's interface, animated sidebar advertisements, and other small page 
> elements of this kind.  This was historically a popular use for 
> animated-GIF, though Flash has largely overtaken it here as well.
> 
> In case 1, a browser on a low-powered device may show the video 
> "full-screen or in an independent resizable window" (to quote the spec). 
> The browser might also show the video at the specified size, but on top 
> of the page, rather than at its "correct" location in the middle of the 
> rendering stack.
> 
> However, for case 2, showing the video full-screen or moving it to the 
> top of the rendering stack would clearly be a bad idea, as the video 
> does not contain the content of interest to the user.  In this case, if 
> browsers cannot display the video as specified, they should probably 
> fall back to the "poster" image.
> 
> With the current tag definition, browsers will have to grow ugly 
> heuristics for this case, based on video's size, aspect ratio, "loop", 
> and "controls".  To avoid this heuristic hack, I suggest that <video> 
> gain an additional attribute to indicate which behavior is preferable.  
> A boolean attribute like "decorative", "incidental", or "significant" 
> would greatly assist browsers in determining the correct behavior.

On Mon, 18 May 2009, Benjamin M. Schwartz wrote:
> 
> Consider a webpage in which a side-effect of clicking on some scripted 
> button is to trigger a small animation (using <video>) elsewhere on the 
> page.  If your browser is configured to show <video> full-screen, this 
> webpage will become nearly unusable, because the small animation will 
> take over the screen every time you click on a button.

I wouldn't expect the user agent to automatically switch to fullscreen 
playback immediately. I would expect the user agent to require the user to 
invoke full-screen mode manually.


> I am proposing an additional attribute for <video> so that the browser 
> will know not to do that.

On Mon, 18 May 2009, Simon Pieters wrote:
> 
> I'm not convinced that an additional attribute would solve the problem: 
> it is likely that some authors would use the attribute incorrectly, 
> because it doesn't have any effect in their primary testing environment. 
> If an author sets the attribute where it shouldn't be set, it 
> effectively makes the video unavailable to users whose UA acts upon the 
> attribute, which seems bad. I think a more effective solution is to give 
> a non-modal message to the user saying "This page is trying to play a 
> video. Press the Foo key to play.", or similar.

On Mon, 18 May 2009, Benjamin M. Schwartz wrote:
> 
> Then I will attempt to convince you.  Suppose the additional attribute 
> is a boolean called "decorative", defaulting to "false" if not present. 
> Authors who are only testing on modern desktops will, as you say, likely 
> ignore this issue.  I therefore fully expect that they will never set 
> this attribute.  If the attribute is not set, then most browsers should 
> assume that the video may be of some significance, and ensure that the 
> user can play it.
> 
> I think the risk of authors accidentally setting "decorative" on 
> critical videos is small.  I also think that if a popular mobile 
> browsing platform were to respect this flag, major websites would use it 
> correctly and user experience would be improved.

On Mon, 18 May 2009, Aryeh Gregor wrote:
> 
> Isn't that like saying that authors who are only testing on normal 
> browsers will likely ignore the longdesc= attribute?  It seems like most 
> authors do just ignore it, but the ones who don't get it wrong far more 
> often than they get it right.  In the ~0.1% of images where longdesc= is 
> used, it's misused literally over 99% of the time:
> 
>    http://blog.whatwg.org/the-longdesc-lottery
> 
> It thus ends up being so useless for users that even if you do provide a 
> good longdesc, no one will actually use it.  There's so little signal 
> and so much noise that screenreader users just don't bother checking it, 
> if they even know that it exists.
> 
> It thus seems like it would be prudent to wait on implementation 
> experience to see if a new attribute is actually needed here.  Adding 
> attributes that don't affect most users is a recipe for widespread 
> misuse.  In the worst case, browsers might very well refuse to support 
> the attribute because it's come into wide misuse before any browser 
> actually supports it, so supporting it breaks sites.  (I'm pretty sure 
> there are examples of this happening, although I can't think of any 
> offhand.)

I concurr with Simon and Aryeh here.


On Mon, 18 May 2009, Benjamin M. Schwartz wrote:
> On Mon, 18 May 2009, Simon Pieters wrote:
> > I think a more effective solution is to give a non-modal message to 
> > the user saying "This page is trying to play a video. Press the Foo 
> > key to play.", or similar.
> 
> Are you going to pop up a message of this kind for every <video> tag on 
> every page?  A page decorated with many small <video> tags in place of 
> animated GIFs is going to be quite difficult to use in a mobile browser 
> where each one is associated with a different approval dialog, and 
> approving causes them to take over the 4-inch screen.

You don't have to show it for each one. You can just have each video that 
the script has triggered provide an affordance (such as a glowing "play" 
button) that triggers the fullscreen mode.


Authors who actually care about this situation (and thus would correctly 
use the proposed attribute) can already use media queries to avoid this 
problem in the first place.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'