On 08/10/2010, at 1:28 PM, "Philip Jägenstedt" <phil...@opera.com> wrote:
> On Thu, 07 Oct 2010 13:18:37 -0700, Silvia Pfeiffer
> <silviapfeiff...@gmail.com> wrote:
>
>> On Thu, Oct 7, 2010 at 4:06 PM, Philip Jägenstedt <phil...@opera.com> wrote:
>>
>>> On Wed, 06 Oct 2010 21:37:06 -0700, Silvia Pfeiffer <
>>> silviapfeiff...@gmail.com> wrote:
>>>
>>> On Tue, Oct 5, 2010 at 10:04 PM, Philip Jägenstedt <phil...@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 <jgra...@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.
>
They all need to be interoperable on all of these features already. It should
be easier to keep them interoperable on something known and already implemented
than on a set of new features, in particular when the new feature set is
restricted and features beyond the limited given set are not available such
that custom "markup" will be produced by plugins etc.
> 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.)
I think that's ok, even though I think it makes more sense to have HTML
fragments than arbitrary markup that is related but somewhat different. I think
we are then just re-inventing HTML.
Cheers,
Silvia.
