W3C home > Mailing lists > Public > www-smil@w3.org > October to December 2008

Re: [whatwg] (X)HTML + SMIL?

From: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>
Date: Sat, 27 Dec 2008 21:35:24 +0000
Message-ID: <49569F9C.30704@googlemail.com>
To: Giovanni Campagna <scampa.giovanni@gmail.com>
CC: robert@ocallahan.org, public-xhtml2@w3.org, www-smil@w3.org

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
Received on Saturday, 27 December 2008 21:36:07 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:53:32 GMT