[whatwg] WebSRT feedback

On Oct 8, 2010, at 2:24 PM, whatwg-request at lists.whatwg.org wrote:

>> Even if very few subtitles use inline SVG, SVG in <object>, <img>,
>> <iframe>, <video>, self-referencing <track>, etc in the cue text, all
>> implementations would have to support it in the same way for it to be
>> interoperable. That's quite an undertaking and I don't think it's really
>> worth it.
>> 
> 
> User agents only need to be interoperable over the common subset of HTML
> features they support. HTML is mostly designed to degrade gracefully when a
> user agent encounters elements it doesn't support. The simplest possible
> video player would use an HTML parser (hopefully off-the-shelf) to build
> some kind of DOM structure. Then it can group text into paragraphs for
> rendering, and ignore the rest of the content.
> 
> In practice, we'll have to deal with user agents that support different sets
> of WebSRT features --- when version 2 of WebSRT is developed, if not before.
> Why not use existing, proven machinery --- HTML --- to cope with that
> situation?
> 
> Rob

The requests we receive on the captioning functionality of the JW Player always revolve around styling. Font size, color, style, weight, outline and family. Block x, y, width, height, text-align, vertical-align, padding, margin, background and alpha. Both for an entire SRT file, for distinct captioning entries and for specific parts of a captioning entry. Not to say that a full parsing engine wouldn't be nice or useful, but at present there's simply no requests for it (not even for <a> ;). Plus, more advanced timed track applications can easily be built with javascript (timed boucing 3D balls using WebGL).

W3C's timed text does a decent job in facilitating the styling needs for captioning authors. Overall regions, single paragraphs and inline chunks (through <span>) can be styled. There are a few small misses, such as text outline, and vertical alignment (which can be done with separate regions though). IMO the biggest con of TT is that it uses its own, in-document styling namespace, instead of relying upon page CSS. 

Kind regards,

Jeroen

Received on Friday, 8 October 2010 06:00:25 UTC