Re: Media Subteam Teleconference Minutes, 8 September

All,

I've reviewed the different sections for concrete changes that we probably
want to see taken as the text is added to the W3C version of the spec. I've
taken some very rough notes below inline that can help us get this started.


ITEM 1. The <track> element

This is specified at
http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#the-track-element.
This is very similar to what we originally developed in this group and has
been further developed and improved, so would be great to get into the W3C
spec for further review and improvement.

On Fri, Sep 10, 2010 at 2:04 AM, Sean Hayes <Sean.Hayes@microsoft.com>wrote:

>  1.       I basically Concur, although it would need to remove specific
> reference to WebSRT. I’m not sure if the intention was ever to use the
> <track> element as  a pointer to a non-text resource, but if it is then the
> kind attribute may need to be able to distinguish between text and audio
> descriptions. I’m also a little concerned about the charset attribute, but I
> don’t think that needs to impede progress.
>

IMO, the only thing the change on item 1 are removal of the following two
paragraphs:

"If the elements's track
URL<http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#track-url>identifies
a
WebSRT<http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#websrt>resource,
and the element's
kind<http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#attr-track-kind>attribute
is not in the
metadata<http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#attr-track-kind-metadata>state,
then the
WebSRT<http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#websrt>file
must be a WebSRT
file using cue text<http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#websrt-file-using-cue-text>
.

If the elements's track
URL<http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#track-url>identifies
a
WebSRT<http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#websrt>resource,
then the
charset attribute may be specified. If the attribute is set, its value must
be a valid character encoding name, must be an ASCII
case-insensitive<http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#ascii-case-insensitive>match
for the preferred
MIME name<http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#preferred-mime-name>for
that encoding, and must match the character encoding of the
WebSRT<http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#websrt>file.
[IANACHARSET]"<http://www.whatwg.org/specs/web-apps/current-work/multipage/references.html#refsIANACHARSET>

Both of these should go into the WebSRT spec at
http://www.whatwg.org/specs/web-apps/current-work/websrt.html as particular
interpretations of the @kind and @charset attribute for WebSRT.



ITEM 2. The Timed Text spec
This is given in
http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#timed-tracks.
This is similar to what we originally developed in this group, but has had
extensive further development and improvements, so would be great to get
into the W3C spec for further review and improvement.

On Fri, Sep 10, 2010 at 2:04 AM, Sean Hayes <Sean.Hayes@microsoft.com>wrote:

> 2.       Again concur, removing the references to WebSRT; and also remove
> the writing direction, snap-to-lines, line position, text position,
> alignment properties and generalise the voice identifier to a list. The text
> of the cue should be a possibly styled HTML fragment.
>

4.8.10.11 shouldn't be added. Other than that, section 4.8.10 uses WebSRT
mostly as a reference to explain things rather than as a need for core use,
apart for this sentence in the TimedTextCue constructor algorithm:

16. Parse the WebSRT
settings<http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#parse-the-websrt-settings>for
cue.

Which should probably read something like: parse the time-synchronized text
track settings for cue.



ITEM 3. The rendering rules
This is given at
http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html#timed-tracks-0.
This is not based on anything that we developed here in this group, but it
is a logical consequence and something we do require to go hand-in-hand with
the other two.

On Fri, Sep 10, 2010 at 2:04 AM, Sean Hayes <Sean.Hayes@microsoft.com>wrote:

> 3.       I think the rendering rules are way too complicated, and WebSRT
> specific and should not be transferred at this time. Although I wouldn’t be
> opposed to a placeholder for it.
>

This section is indeed the most complicated one to make abstract. I would
almost say that it should be replaced by a placeholder something similar to:

"The rules for updating the display of time-synchronized text tracks render
the cues of the timed tracks of a media element by mapping them to a set of
CSS boxes with HTML fragment markup, which user agents are expected to
render either covering the rendering area of the media element or covering
another area dedicated for rendering the time-synchronized text track cues."
That still means that we have to extract the abstract rendering rules from
the text, in particular those that relate to the creation of non-overlapping
CSS boxes for multiple tracks. And we also need something about the CSS
extensions. But there are other proposals on the table that could replace
what is there right now, so I'm happy to go very bare on this section.


Note also that I would like to see the document at
http://www.whatwg.org/specs/web-apps/current-work/websrt.html be completed
with those WebSRT specs that haven't been added there yet. I strongly
believe that a variant of WebSRT would be a great baseline format, so I
would hate to lose any spec text for WebSRT in this process.

Cheers,
Silvia.