On Wed, Aug 18, 2010 at 5:12 AM, Julian Reschke <span dir="ltr"><<a href="mailto:julian.reschke@gmx.de">julian.reschke@gmx.de</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

On 12.08.2010 10:09, Philip Jägenstedt wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
...<div class="im"><br>
The core "problem" is that WebSRT is far too compatible with existing SRT usage. Regardless of the file extension and MIME type used, it's quite improbable that anyone will have different parsers for the same format. Once media players have been forced to handle the extra markup in WebSRT (e.g. by ignoring it, as many already do) the two formats will be the same, and using WebSRT markup in .srt files will just work, so that's what people will do. We may avoid being seen as arrogant format-hijackers, but the end result is two extensions and two different MIME types that mean exactly the same thing.<br>


</div></blockquote>
> ...<br>
<br>
(just observing...)<br>
<br>
So when something that used to be plain text now carries markup, what's the compatibility story for plain text that happens to contain markup characters, such as "<", ">" or "&"?<br>


<br>
Best regards, Julian<br>
</blockquote></div><br>I assume you mean: what happens to text that contains such characters? In most SRT systems, such stuff will just be displayed verbatim.<br><br>Cheers,<br>Silvia.<br><br>