On Tue, Oct 5, 2010 at 10:04 PM, Philip Jägenstedt <span dir="ltr"><<a href="mailto:philipj@opera.com">philipj@opera.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<br>
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.<br>


<br>
As an aside, the idea of using an HTML parser for the cue text wasn't very popular.<br></blockquote><div><br>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.<br>

<br><br> <...></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
* The current syntax looks like XML or HTML but has very different parsing. Voices like <narrator> don't create nodes at all and for tags like <i> the paser has a whitelist and also special rules for inserting <rt>. Unless there are strong reasons for this, then for simplicity and forward compatibility, I'd much rather have the parser create an actual DOM (not a tree of "WebSRT Node Object") that reflects the input. If we also support attributes then people who actually want to use their (silly) <font color=red> tags can do so with CSS. This could also work as styling hooks. Obviously, a WebSRT parser should create elements in another namespace, we don't want e.g. <img> to work inside cues.<br>

</blockquote><div><br>I still believe that in particular <img> and <a> are very important tags to support.<br> </div><br>That was all great feedback, btw!<br><br>Cheers,<br>Silvia.<br><br></div>