Re: (X)HTML5 + SMIL?

Hey Dick,

Maciej also mentioned the difficulty in doing multi-stream synch, but didn't
go into the details.  That's one issue i would be interested in learning
more about, i know that SMIL provides semantics for synchronization
behavior, and i'm not intimately familiar with what the implementation
difficulties would be.  Would you be able to point me to any discussion on
the subject?

Maciej was also aware but somewhat dismissive of SMIL Modularization,
seemingly less for the technical concerns, than the idea that standards that
provide modular support are a bad idea.  I think that's a philosophical
point that can be argued, and i am interested and willing to engage on the
point (it seems particularly crazy to hear coming from someone who belongs
to a community where graceful degradation is so important).

As for who cares or what interest there is, i think that there is raw
interest in what SMIL can provide, i.e. robust timing semantics for media
coordination, but that there is so little awareness by developers and
designers, that it's not actually possible to get informed decisions from
the technical community.

For example, a friend of mine who works for Mozilla decided he wanted to
hack up a slide show using JS, HTML and HTML5's media types.  So he did (
http://labs.toolness.com/ff-herdict-preso/ ) i pointed out that this is
exactly the sort of use case that SMIL is designed for, and that i'd be
willing to hack up the equivalent in SMIL (which i've started doing,
although i'll have the challenge of finding a SMIL player that he can use to
view it, and i may have to default back to Ambulant).

Anyway, it's my conviction that the niche SMIL fills is relevant and useful
(the company i work for is literally building a business around it), and
that if a concerted effort could be made, there would be greater interest in
use of the standard.  There are a variety of impediments to adoption of the
standard at the moment, but most of these (aside from a dearth of usable web
based user-agents), are matters of time, effort and community (things like
publicly accessible, and up-to-date quick references, interesting/relevant
demos, and tutorials on how to accomplish particular tasks in SMIL).  This
is also why i was so dismayed about the SYMM WGs homepage, because it's such
a terrible jumping off point for any potentially interested party. :(

Jeff's point about integration of Time Sheets into XHTML is well taken, but
what i view as a sort of ideal case is some common base where SMIL could be
imbedded into HTML5 and degrade gracefully to clips and images (just the way
that HTML does w/o your CSS positioning), and if you have a JS SMIL player
(or some other sort of player that can pick up on the SMIL document) then
it'll read the SMIL and play properly.

This isn't a question of whether SMIL can or can't be integrated into HTML5
(since you can namespace SMIL into any XML doc yeh?), the question is what's
the best integration that can provide a good user experience, and hopefully
drive better adoption of the standard, if you believe SMIL to be the
appropriate standard for timed media (i'm guessing that's a moot/rhetorical
question here :) ).

-Ted

P.S. i created a #smil channel on irc.freenode.net  I'm sometimes in there,
it'd be great if other people wanted to join me.

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
>