(X)HTML + SMIL?

[Giovanni Campagna]

Very back in 2002, a W3C Note about the integration of XHTML (at that time was 1.1, now it would be 2.0) and SMIL (at that time 2.0, now 3.0). I was wondering if any work was produced because of that document, or it was simply forgotten.

IMHO, it addresses many issues:

1) the video HTML5 element can be replaced by SMIL video into XHTML2 documents, alongside with the SMIL DOM, quite similar to HTML5 media DOM. It also solves accessibility problems such as how to put subtitles into video (use the SMIL Text Module)
2) CSS Transitions, that currently are WebKit propietary extensions, can be implemented using SMIL Animation Module. What is more important, many browsers already implement SMIL Animations on SVG elements, so they could easilily port them to XHTML2 (or 5 if they prefer)

I hope that some work has been done and I'd like answers about that

Giovanni

[bhawkeslewis]

On 27/12/08 16:15, Giovanni Campagna wrote:
> 1) the video HTML5 element can be replaced by SMIL video into XHTML2
> documents, alongside with the SMIL DOM, quite similar to HTML5 media
> DOM. It also solves accessibility problems such as how to put subtitles
> into video (use the SMIL Text Module)

You can of course create compound documents mixing SMIL with XHTML 1.x
or with (the proposed) XHTML2 or with (the proposed) XML serialization
of HTML5. Because of the XML serialization, this isn't a replacement for
a text/html video solution.

Equally, you can use - and always have been able to use - a SMIL object
embedded in a text/html document with the OBJECT element. This suffers
both from poor implementations of OBJECT and dependence on plugins that
makes life more complicated for developers and end-users. Note browser
vendor feedback was that overloading OBJECT to make native video APIs
would be hard for implementers:

* http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-March/010160.html

Likewise, you can embed SMIL as a source for an HTML5 VIDEO element
which (hopefully) will have compatible implementations and be played
natively in the browser, making life simpler for developers and end-users.

To replace HTML5's VIDEO with a SMIL DOM, you'd need to port SMIL to a
text/html serialization. This porting process would be very contentious
and complicated, just as the same process with MathML and SVG is proving
to be.

It's also debatable whether replacing VIDEO with the SMIL DOM would be
desirable in the first place. There has been some criticism of SMIL's
heavy use of namespaces from within WHATWG circles:

    * http://annevankesteren.nl/2005/12/smil
    * http://annevankesteren.nl/2006/03/smil
    * http://www.w3.org/2004/04/webapps-cdf-ws/papers/opera.html

I'd suggest you review the rationale for VIDEO before presenting a case
for replacing it:

* Original video element proposal from Opera (March 2007):
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-February/009702.html 


* Additional proposal from Apple (March 2007):
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-March/010386.html

Initial discussion, if you'd chosen to read it, included both questions
about using SMIL video instead -

    *
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-February/009703.html
    *
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-March/009739.html
    *
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-March/010416.html
    *
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-March/010432.html

- and reasons to prefer VIDEO over SMIL:

* Compatibility with IE's existing text/html implementation of SMIL
would require some sort of namespace support in text/html (WHATWG is
basically namespace-hostile):

http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-March/009729.html

http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-October/012715.html

* "'mediacomplete' seems to require that the video is completely loaded
first which is (a) not always something you want and (b) we have a
'load' event for that"

http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-March/009729.html

* proposed VIDEO API has allegedly clearer names than the SMIL API, more
similar to the Flash familiar to web video developers today:

http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-March/010204.html

http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-March/010217.html

* t:video is not widely used (which may suggest it needs to be improved):

http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-March/010419.html

* the W3C XHTML+SMIL proposal
"http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-October/012719.html 
"doesn't seem to define error handling, nor does it have a corresponding
DOM API... and it is far more complex than the <video> element currently
in the HTML5 draft"

http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-October/012719.html

* "We got strong feedback from existing producers of video on the Web
that their experience with SMIL had been universally disappointing."

http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-October/012715.html

* "SMIL's conceptual model wasn't a good fit for the requirements we had
in mind for <video>." (I'm not entirely sure what was meant there; I
think it's a reference to the opposition to introducing a large
featureset for timed presentations with multiple elements, where HTML5
just wants a way to embed a video simply.)

http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-October/012715.html

http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-October/012718.html

http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-October/016674.html

I don't know enough about SMIL to have a strong position on this stuff
myself (I was one of the people initially wondering why WHATWG wasn't
using SMIL).

But at this late stage, I suppose your best bet would be to present a
detailed proposal for SMIL integration that tries to actually address
these issues.

> 2) CSS Transitions, that currently are WebKit propietary extensions, can
> be implemented using SMIL Animation Module. What is more important, many
> browsers already implement SMIL Animations on SVG elements, so they
> could easilily port them to XHTML2 (or 5 if they prefer)

CSS is for presentation and thus serves a different purpose from SMIL
animations on SVG elements that are presumably part of the content. So
these technologies have different use-cases.

This has also been discussed in the WHATWG archives:

http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-April/010763.html

--
Benjamin Hawkes-Lewis

[Robert O'Callahan-3]

On Sun, Dec 28, 2008 at 5:15 AM, Giovanni Campagna <scampa.giovanni@...> wrote:

2) CSS Transitions, that currently are WebKit propietary extensions, can be implemented using SMIL Animation Module. What is more important, many browsers already implement SMIL Animations on SVG elements, so they could easilily port them to XHTML2 (or 5 if they prefer)

CSS Transitions and SMIL Animations are actually quite different. CSS Transitions provide for smooth transitions whenever the computed value of a CSS property changes; they provide no way to actually *cause* a change in a property value. SMIL can cause changes in property values (changes that occur during the cascade and therefore can be inherited etc), but it can't automatically smooth transitions whenever a CSS computed value changes.

Because they're complementary, at Mozilla we're keen to support both CSS Transitions and SMIL Animations (for SVG, at least). But discussion of CSS Transitions vs SMIL Animation should happen on www-style, not in the public-xhtml2 or whatwg lists.

Rob
--
"He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all." [Isaiah 53:5-6]

[Giovanni Campagna]

I'm sorry you misunderstood my question, that was: has W3C planned any work about XHTML2 + SMIL
Then I presented two use cases (video and animation).
But there are other use cases, for example something like a web presentation which includes XHTML content (ie. mostly tables or forms, since all the rest is achievable by other means).

It was not my intention to discuss about video in SMIL vs video in HTML or CSS Transitions vs SMIL Animations.

I hope I clarified

Giovanni

PS:
@Bernard Hawkes Lewis
1) Smil 3.0 uses only one namespace. I don't know if Anne was wrong or Smil 2.1 was different.
2) video in smil is not used because it doesn't work (nor it does HTML5 video, unless you get FF3.1 beta, Opera 10 alpha, WebKit nightlies with explicit configuration)
3) SVG animations are teorethically part of content, but this has no actual impact (do you expect that a screen reader will describe the animation?)

@Robert O' Callahan
Yes but they have completely different syntaxes. From an author point of view, integration is not that bad.
Besides, CSS Animation (which is mentioned in CSS CurrentWork and will maybe be introduced in CSS4) is actually very similar to SMIL Animation (only how property changes, not why)

[Robert O'Callahan-3]

On Sun, Dec 28, 2008 at 8:28 AM, Giovanni Campagna <scampa.giovanni@...> wrote:

@Robert O' Callahan
Yes but they have completely different syntaxes. From an author point of view, integration is not that bad.

Yes, but the CSS Transitions syntax is far better than the SMIL syntax, for several reasons (being purely CSS-based is one reason). Trying to synchronize the syntax would destroy that and doesn't seem worth it.

Besides, CSS Animation (which is mentioned in CSS CurrentWork and will maybe be introduced in CSS4) is actually very similar to SMIL Animation (only how property changes, not why)

Indeed, and we are much less interested in Apple's CSS Animation proposal than CSS Transitions.

Rob
--
"He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all." [Isaiah 53:5-6]

[bhawkeslewis]

On 27/12/08 19:28, Giovanni Campagna wrote:
> I'm sorry you misunderstood my question, that was: has W3C planned any
> work about XHTML2 + SMIL

Like what exactly?

You can already mix SMIL or (draft) XHTML2 with any other XML language.

There is a working group working on making such mixing work _better_,
but that working group isn't addressed in your email:

http://www.w3.org/2004/CDF/

But it seems like what you want is duplication of SMIL features to the
XHTML2 language itself?

So are you proposing things like the addition of the SMIL timing
attributes to XHTML2?

http://www.w3.org/TR/SMIL3/smil-timing.html#q48

> Then I presented two use cases (video and animation).
> But there are other use cases, for example something like a web
> presentation which includes XHTML content (ie. mostly tables or forms,
> since all the rest is achievable by other means).
>
> It was not my intention to discuss about video in SMIL vs video in HTML
> or CSS Transitions vs SMIL Animations.

Sorry, you mentioned replacing VIDEO and CC'ed WHATWG, so I thought you
were proposing a change to the HTML5 specification.

> @Bernard Hawkes Lewis

Benjamin, actually. :)

> 2) video in smil is not used because it doesn't work (nor it does HTML5
> video, unless you get FF3.1 beta, Opera 10 alpha, WebKit nightlies with
> explicit configuration)

SMIL video works in a bastardized form in text/html in the browser most
people use (Internet Explorer), and it was introduced at a time when it
was even more dominant than it is now and when IE-only sites were
commonplace.

> 3) SVG animations are teorethically part of content, but this has no
> actual impact (do you expect that a screen reader will describe the
> animation?)

I think keeping presentational information in a seperate presentational
layer (CSS) is a mission-critical part of modern web development.

The needs of screen readers are far from the only reason for this. Other
reasons include:

    * Easier maintenance
    * Ability to turn off presentations that are unwanted for
accessibility or user-preference reasons (e.g. publisher colors,
unnecessary epilepsy-triggering animations, reading-disrupting marquees,
removal of underline on links)
    * Ability to offer multiple presentations for the same content.

And yes, I'd expect timing synchronization of content to be reflected by
ideal assistive technology.

--
Benjamin Hawkes-Lewis

[Jack Jansen]

On  27-Dec-2008, at 20:28 , Giovanni Campagna wrote:

I'm sorry you misunderstood my question, that was: has W3C planned any work about XHTML2 + SMIL
Then I presented two use cases (video and animation).

The problem with XHTML+SMIL is that it never got into the REC track, because there was no second implementation, Microsoft's HTML+TIME is the only one. This is a shame, because some of the ways XHTML+SMIL allows reuse of SMIL global timing constructs in other languages are pretty neat and non-intrusive. The microformats work seems to be built heavily on this (or they re-invented the same concepts in parallel), it would be very interesting to see if XHTML+SMIL could  be revived in the light of what has been done in microformats and other fields in recent years.

Another angle of work that came out of XHTML+SMIL is SMIL Timesheets (http://www.w3.org/TR/2008/WD-timesheets-20080110/), but it takes a different approach: it separates the SMIL containment model from the HTML/XML containment model by using selectors to bind the two, thereby allowing reuse of the single timing document on multiple similar HTML document, similar to stylesheets (hence the name Timesheets). Timesheets currently has a similar problem as XHTML+SMIL: it needs some more momentum behind it.

The SYMM working group is currently actively investigating the possibilities of continuing work on XHTML+SMIL, Timesheets or a combination of the two. If people are interested in this area: please join the SYMM WG. And (to put a little pressure on:-): please join the working group soon, there's decisions to be made that may require a charter extension, and if the group decides there's not enough momentum to warrant that commitment, it may be years before the chance arises again.

--

Jack Jansen, <Jack.Jansen@...>, http://www.cwi.nl/~jack

If I can't dance I don't want to be part of your revolution -- Emma Goldman

[Giovanni Campagna]

2008/12/29 Jack Jansen <Jack.Jansen@...>

On  27-Dec-2008, at 20:28 , Giovanni Campagna wrote:

I'm sorry you misunderstood my question, that was: has W3C planned any work about XHTML2 + SMIL
Then I presented two use cases (video and animation).

The problem with XHTML+SMIL is that it never got into the REC track, because there was no second implementation, Microsoft's HTML+TIME is the only one. This is a shame, because some of the ways XHTML+SMIL allows reuse of SMIL global timing constructs in other languages are pretty neat and non-intrusive. The microformats work seems to be built heavily on this (or they re-invented the same concepts in parallel), it would be very interesting to see if XHTML+SMIL could  be revived in the light of what has been done in microformats and other fields in recent years.

Another angle of work that came out of XHTML+SMIL is SMIL Timesheets (http://www.w3.org/TR/2008/WD-timesheets-20080110/), but it takes a different approach: it separates the SMIL containment model from the HTML/XML containment model by using selectors to bind the two, thereby allowing reuse of the single timing document on multiple similar HTML document, similar to stylesheets (hence the name Timesheets). Timesheets currently has a similar problem as XHTML+SMIL: it needs some more momentum behind it.

This idea (Timesheet) is very good, beacuse it resolves a structural problem, allowing to separate content from presententation from timing from action, that is XHTML from CSS from SMIL from ES.
But you need to cooperate with the other wg in the interaction domain, because they're already working on different solution (eg CSS Animation), which implement a different model. If you want to keep work done until now, with 3 TRs that successfully reached REC, you need to move quickly.
Also Timesheet will solve issues like applying Timing to a wide number of element, by using CSS3Selectors, that are widely used and understood.
 

The SYMM working group is currently actively investigating the possibilities of continuing work on XHTML+SMIL, Timesheets or a combination of the two. If people are interested in this area: please join the SYMM WG. And (to put a little pressure on:-): please join the working group soon, there's decisions to be made that may require a charter extension, and if the group decides there's not enough momentum to warrant that commitment, it may be years before the chance arises again.

I personally cannot join the WG (i'm free in these days because of winter holidays, the rest of the year I'm quite busy). But I think that people will like integration of SMIL into existing profiles like XHTML+SVG, allowing to eventually defeat Adobe Flash monopoly.
Maybe you could join the Compound Document WG: SMIL itself is quite a niche language, SMIL+XHTML+SVG is the future of web.

Giovanni