Re: SMIL and <video> accessibility

On Tue, Feb 16, 2010 at 10:44 AM, Geoff Freed <geoff_freed@wgbh.org> wrote:
>
> With all this discussion over the past week regarding the coordination of <video> with caption/subtitle/description/karoke, etc., tracks, I am reminded of a question that I and a few others asked last fall when this group was formed:  why is SMIL not being considered to take care of track synchronization, selection and activation?  I know that there were objections to the size of SMIL, but there wasn't much discussion about implementing only specific modules rather than the whole huge spec.  All this talk about <tracks> and <trackgroup> make me think we should be taking advantage of SMIL's <par> and <switch> elements, for example.
>
> So... what are the reasons SMIL modules (http://www.w3.org/TR/SMIL/smil-modules.html) aren't being considered?
>
> Thanks.
> Geoff/WGBH
>

Hi Geoff,

I can only give you my personal viewpoint on this. I am not sure what
others think, but I have in several occasions tried to re-use SMIL
modules or even just SMIL elements, so I will give you my personal
experience.

SMIL was created for a media-centric world-view: everything in SMIL
would be able to deal with multiple timelines, any kind of media could
be used and aligned in any possible way. And everything would be
specified right there inside a SMIL xml file and a media engine would
need to interpret it all and execute the expected presentation.

Now, all of SMIL is obviously not interesting for HTML, since a lot of
what SMIL does is already supported in other ways in HTML. There is
javascript, for example, for doing animations and the like. There is
normal HTML layout, which does much better than SMIL at 2D layouts -
things that happen over time are a fairly new concept to HTML and
there is a lot to learn from SMIL for that, indeed. So, all of SMIL
can obviously not be merged into HTML.

So, what about modules? Or even just taking specific elements and
reusing them as they are?

The problem with that approach is that you get the good with the ugly.
I've tried on many occasions to re-use sections of SMIL, since a lot
of good ideas have gone into SMIL. However, every single time I have
found myself in a position, where one of three things - most of the
time all three things - happened:
* the SMIL definition was just slightly off from the definition that I needed
* the SMIL element had attributes that I didn't need
* the SMIL element lacked attributes that I needed
On top of that, the naming of the attributes would have been very
different to the way in which the naming scheme worked that I had
used.

I believe that is the case with HTML as well.

There are many ideas in SMIL and possibly many element names that we
may need to introduce into HTML. But they may turn out to be used very
different to the way that SMIL uses it, because the use cases and
needs are different.

So, even if we used <par> for something like describing parallel
tracks (which, incidentally, I think is totally an option), I don't
think the HTML <par> element would look exactly the same as the SMIL
<par> element. Use cases are different, so markup will turn out
different.

As you have followed the captions discussion, you will have seen many
different proposals and many different name changes. The media
subgroup is struggling heavily with getting this right. If you want to
contribute a proposal that is directly taken out of SMIL, feel free!
It may well turn out to be a good choice, but because of my above
experiences, I highly doubt it would end up being just a SMIL module -
it could, however, end up being one or more of the SMIL elements with
different attribute names.

So, if you think a SMIL module is appropriate for solving a particular
issue, I don't think anyone will object to a concrete proposal for
reusing something particular. You'd have to show how it satisfies the
requirements and what markup would be used, but that's what we all do
all the time.

I've seen it work well for Microsoft's IIS Smooth Streaming Server
Manifest, where the document structure of their SMIL files was
restricted and attributes removed, but they were essentially able to
create their manifest using just SMIL constructs. Reuse is possible -
you may just need to be flexible in what may get adapted.

Cheers,
Silvia.

Received on Tuesday, 16 February 2010 00:40:17 UTC