Re: (X)HTML5 + SMIL?

I've realize that i should have given a more concise and pointed reply.

I appreciate that the HTML5 process is being run by people who are employed
at places like Google and Apple.  I don't think this is an issue, and in
fact, i think it provides some opportunities and levers that otherwise would
be unavailable.

SMIL provides capabilities which a lot of people currently rely upon
Flash/Silverlight for.  If the browser/HTML5 guys care about an web that's
based around open and free standards (and i'm sure employees who work at
Apple do), then SMIL has a role to play (or something equivalent to SMIL).
 The reality is that while HTML5+JS or HTML5+CSS Animation can provide a lot
of interesting functionality, some of which overlaps with SMIL or SVG+SMIL
animation, they do not provide the same framework that SMIL does,
particularly if one were interested in doing things like DOM manipulations
on timed presentations.

Ultimately this comes down to what we want to enable users to do.  If there
are people who are allergic to SMIL, that's not a technical justification of
why one might want to hobble users.  And if users are paramount, hopefully
prejudice will give way.  It seems silly to not bother to make a case at
all.

-Ted

On Fri, Mar 5, 2010 at 8:47 AM, Dick Bulterman <Dick.Bulterman@cwi.nl>wrote:

> The lack of HTML+SMIL integration is due to a number of factors. I tried to
> raise the issue on mult-stream synchronization when HTML5 introduced the
> video tag, and I've been trying more recently to raise some of the issues
> within the html-a11y group.
>
> Apparently, some on the HTML5 group are unaware of SMIL's modularization:
> they seem to think you need to take everything, instead of just the modules
> you need. Others are -- quite frankly -- allergic to all things SMIL.
>
> The discussions on the SMIL/HTML5 integration are not particularly
> technical, but they do revolve around a key point: who within the user
> community cares? If people have integration needs, I'd be happy to
> coordinate presentation via the HTML WG. Keep in mind that the resolution of
> these issues is slightly different than standard W3C process, and are
> influenced heavily by the preferences of various browser implementers.
>
> Dick Bulterman
> co-chair, SYMM
>