Re: Text associations for HTML5 video/audio

On Sat, Apr 17, 2010 at 3:49 AM, Sean Hayes <Sean.Hayes@microsoft.com> wrote:
> Dick, if I'm reading this right the key difference here is to replace the enabled attribute with the <systemTest> attributes, as replacing the trackgroup element with  <switch> is largely syntactic (although I understand the premise of keeping it in synch with SMIL) .
>
> In principle this seems like an OK change, however your examples confuse me,
>
> You define the attribute:
>
>          attribute DOMString systemTest;
>
> but then you introduce a totally different attribute in the examples, for instance:
>
> Example 1: Simple conditional inclusion of a default captions file.
>
>   ...
>   <video src="movie.mp4" controls ... >
>      <textstream src="movie.srt" systemCaptions="true" ... />
>   </video>
>   ...
>
> If the intention is to include a full gamut of predefined System Test attributes, like SMIL does, then I think this is problematic; as it requires a DTD alteration for each system test and I think it's unlikely we will be able to agree on the right set quickly enough. If on the other hand we have something like:
>
>   <video src="movie.mp4" controls ... >
>      <textstream src="movie.srt" systemTest="captions: true" ... />
>   </video>
>
> Then this is better from a DTD point of view, but essentially boils down to the same mechanism as the media queries.
>
> What did you have in mind here?
>


Having read the proposal thoroughly, I have to concur with Sean. I
actually think that the basis for some of these suggestions may be
some fundamental misunderstandings of HTML. Let me elaborate.

The main push of this proposal is the introduction of a mechanism to
introduce predicates into media elements. Predicates here mean the
testing of system conditions to enable or disable elements, in
particular user preference settings.

Now, HTML is a language used by a Web developer to declare the layout
and displayed elements of a Web page. A Web developer can not declare
in an attribute value what state a system is or should be in. The
state of a system is inherently dynamic from the point of view of the
Web page and the Web developer and has to be evaluated at the time
that the Web page is rendered.

There is only one approach towards predicates available in HTML that I
am aware of: it is the media queries, which is being used through the
@media attribute. Traditionally in HTML4 it has been used mainly to
select a different style sheet for a Web page depending on the output
device. For the media elements, @media filters based on certain
conditions that allow to select different resources based on what they
have been tailored for.

This is not quite the same as system test conditions, but close
enough. In fact, media queries for media elements and their resources
have not really been analysed in-depth yet. There are existing
proposals to extend media queries beyond describing what device a
resource was made for to also describe what user preferences a
resource will satisfy. Things such as
accessibility(audiodescription:yes) or accessibility(caption:yes) have
been proposed. We will have to pursue this further.

Note that the @language, @role and @type elements are not there to
define predicates but to describe features of the media resource. What
effect these features have depends completely on the UA. In HTML we
cannot assume what functionality aside from interpreting the HTML page
a UA may implement. It is possible to recommend certain user
preferences, but it is not possible to require them. In fact, those
media queries are not part of HTML, but of CSS. All we can do at the
HTML level is to make sure that the UA has sufficient information to
make decisions in certain circumstances - such as a user preference
for captions.

So, to cut a long story short, system tests have to be evaluated
dynamically and cannot be an attribute value. For describing what
situation a media resource targets we already have the media queries
attribute. (Just as Sean said above, but in more detail).


Further feedback on the other changes:

* you removed the @enabled attribute. This may be a consequence of
introducing systemTest, as I think Sean assumes, but it removes the
possibility for the Web author to express their opinion on what
element should be active. This is a step back. We require both
functionalities : a user to express their preference and a Web author
to express their preference. Only then can the UA make an informed
decision as to what to display.

* you renamed <track> to <textstream>. That is a problem, since we
want to explicitly allow in future for other dependent media resources
to be declared as dependent tracks towards the dominant <audio> or
<video> resource. E.g. we want to allow audio files to be associated
through the <track> element, where e.g. the audio file would be a
audio description. Thus, I don't think we can do this change.

* you renamed <trackgroup> to <switch>. If we were to adopt all of
<switch> in SMIL, with all its attributes and its selection algorithm,
then that would be an obvious choice. Since our <trackgroup> element
has different attributes to the SMIL <switch> element, this obviously
isn't the case. We could still adopt the SMIL name, but it could be
confusing since the same element name would be used for two different
things. Right now, the choice of name of "trackgroup" has been
inspired by MPEG which uses "trackgroup" to signify tracks inside an
MPEG file that are mutually exclusive.

To be honest, I am not opposed to renaming <trackgroup> to <switch>.
It does, after all, describe alternative resources. But we cannot
change the selection algorithm for the <track> elements inside it from
a mere listing of alternatives to a active selection mechanism (see
reasons above). Everything else about <trackgroup> would need to
remain and we would just change the name to <switch>.

Cheers,
Silvia.

Received on Tuesday, 20 April 2010 14:40:41 UTC