Re: HTML 5, SMIL, Video

Hi Dick,

On Thu, Feb 18, 2010 at 8:47 PM, Dick Bulterman <Dick.Bulterman@cwi.nl> wrote:
>
> SMIL has an extensive profile architecture which allows a language designer
> to select appropriate attributes -- you don't need to take everything. (It
> isn't CSS!)

Profiles are element groupings for a particular purpose. I regularly
check back with the available SMIL modules, but honestly haven't seen
a use case where a SMIL module would have been the answer.


>> There are many ideas in SMIL and possibly many element names that we
>> may need to introduce into HTML. But they may turn out to be used very
>> different to the way that SMIL uses it, because the use cases and
>> needs are different.
>>
>> So, even if we used <par> for something like describing parallel
>> tracks (which, incidentally, I think is totally an option), I don't
>> think the HTML <par> element would look exactly the same as the SMIL
>> <par> element. Use cases are different, so markup will turn out
>> different.
>
> Our position has always been straightforward: control primitives (either
> elements or attributes) that do similar things in SMIL and HTML+Video should
> have similar definitions and similar names. Control primitives that are
> different (in as far as they are REALLY needed), should be structured so as
> to avoid confusion by users. This does require some flexibility, especially
> by HTML-5, since temporal control is -- as you point out -- new.

I'm sure when a control primitive out of SMIL and out of HTML5 have
the same name, we will make sure they do the same thing so as not to
confuse users and in particular parsers.

Incidentally, we have just looked at what names to use for roles of
the tracks of media elements and have harmonised the naming with the
names chosen in SMIL.


>> As you have followed the captions discussion, you will have seen many
>> different proposals and many different name changes. The media
>> subgroup is struggling heavily with getting this right. If you want to
>> contribute a proposal that is directly taken out of SMIL, feel free!
>> It may well turn out to be a good choice, but because of my above
>> experiences, I highly doubt it would end up being just a SMIL module -
>> it could, however, end up being one or more of the SMIL elements with
>> different attribute names.
>
> On this topic, I really suggest that you take the time to read the smilText
> module definition. SmilText was designed to address text timing and text
> motion in an easy to implement fashion -- something near the complexity of
> SRT, but in an XML format that allows for trivial integration into HTML or
> any other XML language. It is (I think) a nice compromise between DFXP and
> other timed-text, plus it is fully streamable (and works transparently with
> CSS).

There are two aspects to the external caption discussion: one is the
declarative markup for how to reference them - which I believe was the
discussion that was the source of Geoff's comment - the other one is
about formats. SmilText could be regarded as an additional format for
browser vendors to support over the currently proposed DFXP and SRT.
If the choice was between DFXP and SmilText, which do you think have
larger market uptake and are supported by more applications? Also,
which do you think is more powerful?

To me they look fairly similar and both have - from the POV of HTML -
the problem that layout, styling, and animation have to be mapped onto
the constructs that HTML, CSS and JavaScript use for the Web. The
discussion has, however, been raised that it may be possible to create
profiles of DFXP and that the baseline profile for support in browsers
may be a small subpart of DFXP. Maybe SmilText matches that need. From
what I have seen of SmilText, I believe, however, that a basline DFXP
profile may need to be simpler still than SmilText.

One thing that would help create support for, in fact, any format in
browser is a JavaScript based demonstration of how to interpret the
constructs in a Web scenario. Right now we have several srt
demonstrations, and a partial DFXP demonstration is at
http://www.w3.org/2009/02/ThisIsCoffee.html . Maybe the features used
in that DFXP demonstration could make up a profile? If you are keen to
push smilText, you should get involved in the discussions in the
accessibility task force, develop demos, and help others understand
why it is the best choice.


>> So, if you think a SMIL module is appropriate for solving a particular
>> issue, I don't think anyone will object to a concrete proposal for
>> reusing something particular. You'd have to show how it satisfies the
>> requirements and what markup would be used, but that's what we all do
>> all the time.
>
> When I suggested that SYMM formulate a concrete proposal, I was told that
> there was no more time: HTML-5 was going to rec, and no new work would be
> considered. I'm pleased to read that this position has evidently changed.
>
> If there is an interest in brainstorming about the place of SMIL
> timing/synchronization, I'd be glad to help with a strawman proposal or to
> walk thru the main attributes (and their purpose) at a group meeting in
> Boston. The same is true for SMIL Text and media content. I'd also be happy
> to discuss specific questions on elements and attributes via these lists.
>
> Personally, I think it would be silly to reinvent the timing/synchronization
> wheel. I'm open to pragmatic solutions.

The best way to contribute is to get involved in discussions on the
public-html and the public-html-a11y mailing list and to make concrete
proposals that solve use cases under discussion. These are the places
(aside from whatwg) where specifications for html5 are still being
discussed and created.


Best Regards,
Silvia.

Received on Thursday, 18 February 2010 11:38:32 UTC