Re: Initial version of Synchronization Issues

I agree with Sean's analysis. I have only one feedback inline below.

On Thu, Apr 8, 2010 at 8:27 AM, Sean Hayes <Sean.Hayes@microsoft.com> wrote:
> Dick, while this is a well-argued and reasoned critique of the HTML video and audio elements, I feel that apart from noting that trackgroup is in effect a specialised version of switch, it doesn't have that much bearing on the text association mechanism proposed, which is intended to fit within the current framework.  I suggest the real audience for this document is the wider WG.
>
> Concentrating specifically on the text association mechanism: even if switch were to be adopted instead of trackgroup, one would still need the attributes of trackgroup for accessibility, in order that the UA could direct information to AT and present a coherent set of choices to the user.
>
> You state that trackgroup has a limitation that it would not be possible to select subtitles in, for example, both Dutch and German simultaneously; however using switch with systemLanguage as you suggest, would actually create exactly such a restriction since according to the spec the switch would select only the first language matched [To allow this, the author would need to  supply N switch groups all possible permutation of language order].  Adopting a SMIL approach would largely constrain implementation in exactly the manner you warn against.
>
> In fact I'm starting to feel that the text association attributes (@role etc) should simply identify the intended semantic of the resource or group of resources, but that the spec should not necessarily place a constraint on the selection behaviour of the UA with respect to that resource. A UA (or the JS API) could then in fact enable any all or none of the <track> resources in a role group, (and some might be enabled in the UA itself and some to AT); this would be UA specific behaviour.  The spec would need to sufficiently constrain the rendering behaviour of multiple enabled tracks for interoperability of content, and guarantees of access, but doesn't need to be overly prescriptive.

SP:
Note that in the current specification the @role, @type, @name, and
@language attributes are not actually used to constrain the selection
within the <trackgroup>. Instead, they are only there to allow
avoiding to replicate these attributes in every <track> inside the
<trackgroup>. They are just descriptive attributes, not the basis for
a selection decision. The <trackgroup> only specifies that of the
tracks inside it at most one track can be active at one point in time.
If you want to allow activation of more than one <track> at a time,
don't put them in a <trackgroup>. Then you can have total flexibility
with the tracks and have them enabled from the UA or AT or JavaScript.
So, this functionality is already available.


> On balance I feel that unless you are successful in getting the WG to adopt the SMIL content switch mechanism within the wider <audio> and <video> element (and as stated we would still need additional information from the text association document in such a case), that replacing <trackgroup> with <switch> would be somewhat misleading and not especially fruitful.
>
> You also state:
> "The layout behavior is not directly specified". -- this is largely deferred to the text format itself, but the bounding rectangle will be well defined.
>
> "but it a richer set of possibilities (below, on top, along side the video) could also be useful, especially for accessibility applications."
> This will be possible (using TTML and the extent=container attribute value we have proposed in email)  if the content author wished it


Regards,
Silvia.

Received on Thursday, 8 April 2010 00:23:52 UTC