[whatwg] WebSRT feedback

[Philip Jägenstedt]

On Thu, 07 Oct 2010 13:18:37 -0700, Silvia Pfeiffer  
<silviapfeiffer1 at gmail.com> wrote:

> On Thu, Oct 7, 2010 at 4:06 PM, Philip Jägenstedt <philipj at opera.com>  
> wrote:
>
>> On Wed, 06 Oct 2010 21:37:06 -0700, Silvia Pfeiffer <
>> silviapfeiffer1 at gmail.com> wrote:
>>
>>  On Tue, Oct 5, 2010 at 10:04 PM, Philip Jägenstedt <philipj at opera.com
>>> >wrote:
>>>
>>>
>>>> Styling hooks were requested.If we only have the predefined tags (i,  
>>>> b,
>>>> ...) and voices, these will most certainly be abused, e.g. resulting  
>>>> in
>>>> <i>
>>>> being used where italics isn't wanted or <v Foo> being used just for
>>>> styling, breaking the accessibility value it has.
>>>>
>>>> As an aside, the idea of using an HTML parser for the cue text wasn't
>>>> very
>>>> popular.
>>>>
>>>>
>>> I believe that this feedback was provided by a person representing the
>>> deaf
>>> or hard-of-hearing community and not the subtitling community. In
>>> particular
>>> at FOMS I heard the opposite opinion.
>>>
>>
>> Is "this feedback" about styling hooks or HTML as the cue text format?
>> Both?
>
>
>
> Oh, it was about the last sentence: about using HTML fragments in cue  
> text.
>
>
>
>>
>>
>> On Thu, 07 Oct 2010 01:57:17 -0700, James Graham <jgraham at opera.com>
>> wrote:
>>
>>  On 10/06/2010 04:04 AM, Philip Jägenstedt wrote:
>>>
>>>  As an aside, the idea of using an HTML parser for the cue text wasn't
>>>> very popular.
>>>>
>>>
>>> Why? Were any technical reasons given?
>>>
>>
>> The question was directed at the media player/framework developers  
>> present.
>> One of them didn't care and one was strongly opposed on the basis of  
>> bloat.
>> This was an aside, if anyone is serious about using the HTML fragment  
>> parser
>> for WebSRT, we really should approach the developer mailing lists of  
>> media
>> players/frameworks. I doubt we will find much love, but would be happy  
>> to be
>> shown wrong.
>
>
>
> The one I talked to said that HTML markup should totally be used in cues  
> (he
> even mentioned more generally why we didn't pick up USF). The reason  
> being
> that it clearly defines extensibility and would in fact already provide  
> any
> use case that anyone can come up with, thus stopping people from  
> inventing
> their own screwed up extensions, such as the use of ass commands in {}
> inside srt subtitles.
>
> The thing is: while the full set of features of HTML fragments seems  
> bloat,
> not every subtitle will consist of all the possible markup. Just like Web
> pages are often created with very simple markup which uses less then 1%  
> of
> what HTML is capable of, we will see the same happening with subtitle  
> cues.
> But the availability and clear definition of how such features should be
> used prevents the introduction of crappy extension.

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.

As for extensibility, I suggest that we generalize the WebSRT parser  
somewhat to produce a normal DOM with elements in a non-HTML namespace and  
then use CSS to style them as usual. Unknown element names shouldn't be  
valid, of course, but they'd still appear in the DOM. If "XML5"  
(http://annevankesteren.nl/2007/10/xml5) was ready, I'd suggest we use  
that, with the constraint that it should only be able to output elements  
in that non-HTML namespace. (Just thinking out loud here.)

-- 
Philip Jägenstedt
Core Developer
Opera Software