[Bug 13436] Editorial changes to The Video element (4 of 5)

http://www.w3.org/Bugs/Public/show_bug.cgi?id=13436

--- Comment #11 from Shelley Powers <shelleyp@burningbird.net> 2011-08-13 05:15:07 UTC ---
(In reply to comment #10)
> (In reply to comment #9)
> > (In reply to comment #8)
> > > (In reply to comment #7)
> > > > (In reply to comment #6)
> > > > "means that UAs have to follow it
> > > > > unless they have a good reason not to."
> > > > 
> > > > This is a vague phrase that means very little from a technical perspective. The
> > > > UA may decide the "good reason" is because they just don't feel like doing it.
> > > > It's entirely subjective. 
> > > 
> > > You don't understand what the RFC 2119 keywords mean.  Please read
> > > http://www.ietf.org/rfc/rfc2119.txt
> > 
> > And the HTML5 spec states UAs "should" display the video control when scripting
> > is disabled, yet only one UA does. So much for "should".
> 
> You don't understand how to file browser bugs.


And you don't know how to respond in a constructive manner in bug threads. 

> 
> > There is no reason not to provide a facility to choose tracks if the control is
> > displayed. Well, unless there's a particular reason to deliberately disable
> > video accessibility. Is there a reason to deliberately disable video
> > accessibility? 
> > 
> > What is one good use case for not ensuring this capability?
> 
> The spec doesn't mandate UI.


When the progress binding applies to a progress element, the element is
expected to render as an 'inline-block' box with a 'height' of '1em' and a
'width' of '10em', and a 'vertical-align' of '-0.2em'.

When the element is wider than it is tall, the element is expected to be
depicted as a horizontal progress bar, with the start on the right and the end
on the left if the 'direction' property on this element has a computed value of
'rtl', and with the start on the left and the end on the right otherwise. When
the element is taller than it is wide, it is expected to depicted as a vertical
progress bar, with the lowest value on the bottom. When the element is square,
it is expected to be depicted as a direction-independent progress widget (e.g.
a circular progress ring).

User agents are expected to use a presentation consistent with platform
conventions for progress bars. In particular, user agents are expected to use
different presentations for determinate and indeterminate progress bars. User
agents are also expected to vary the presentation based on the dimensions of
the element.

For example, on some platforms for showing indeterminate progress there is an
asynchronous progress indicator with square dimensions, which could be used
when the element is square, and an indeterminate progress bar, which could be
used when the element is wide.

Requirements for how to determine if the progress bar is determinate or
indeterminate, and what progress a determinate progress bar is to show, are
included in the definition of the progress element.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

Received on Saturday, 13 August 2011 05:15:10 UTC