Re: text-format discussion from today's call

Hi Sean,

On Sun, Aug 8, 2010 at 1:55 AM, Sean Hayes <Sean.Hayes@microsoft.com> wrote:

>  Actually I think there is a typo in the WebSRT description. As it does
> preclude cues that start at the same time, not surprising for a new
> un-implemented spec.
>
> The time represented by this WebSRT timestamp<http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#websrt-timestamp>must be greater than the start time offsets of all previous cues in the file
>
> But as you say the abstract cue list allows for it; so I think this must be
> an error.
>


Oh, that totally slipped by me. Indeed, I think that's an error and maybe a
left-over from an earlier draft. I have found other errors, too. Would you
mind if I alert the WHATWG to it?



> It also needs the ability to record both the vertical and horizontal size
> of the cue in order for this to work properly (e.g. capture 608 captions).
>

Yes, I agree and have also given that feedback. I proposed it should be the
minimum width and height that the cue requires to be rendered. Do you think
that captures this?



>  It also has a very flat markup structure, so it can’t be styled to the
> same extent as TTML (without using some text selection type selectors which
> would be very clunky). For example having bold italic would be a problem.
>

I think you can put bold and italic around a word. Or did you see something
disallowing that? However, I agree that the styling is very restricted and
have proposed to include the full power of CSS rather than restricting it to
a very limited subset.



>  In a sense one can think of WebSRT as ‘unrolled’  TTML. It is possible to
> compute all of the ‘events’ from a TTML file and map them to this cue
> architecture, although I think a cue should just have an HTML fragment as
> its payload, and leave it to formats to define how they map to the HTML
> fragment.
>

I completely agree that HTML should be the payload that is expected from the
TimedTrack interface rather than the WebSRT stuff. That would allow other
formats to map to HTML rather than having to map to the limited WebSRT
structure.
And I also think that WebSRT should support proper HTML fragments in the
cues, which can be done in addition to the limited markup it currently
supports.


Cheers,
Silvia.