Re: SMIL and <video> accessibility

I have to strongly second Geoff's comments.

Granted that there has been concern that SMIL is too large and
implementation would be a burden UAs don't want, the idea behind SMIL
modularization was to allow selecting only those modules that are needed.

This approach was successfully followed by the DAISY talking book community,
which needed only a subset of SMIL to enable text/audio synchronization for
talking book players (with implementations spanning small custom hardware
devices through desktop players).

SMIL appears provides everything needed.  It seems this effort is
reinventing elements that are already spec'd.  I'd be interested in learning
why SMIL is not suitable.

mark



On Mon, Feb 15, 2010 at 6:44 PM, 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
>
>