- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Wed, 18 Aug 2010 09:14:19 +0200
On 18.08.2010 00:43, Silvia Pfeiffer wrote: > On Wed, Aug 18, 2010 at 5:12 AM, Julian Reschke <julian.reschke at gmx.de > <mailto:julian.reschke at gmx.de>> wrote: > > On 12.08.2010 10:09, Philip J?genstedt wrote: > > ... > > 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. > > > ... > > (just observing...) > > 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 "&"? > > Best regards, Julian > > > I assume you mean: what happens to text that contains such characters? > In most SRT systems, such stuff will just be displayed verbatim. Yes, in SRT. But in WebSRT? Isn't there a compatibility problem when the format just switches from plain text to possibly escaped text? (I recall the problems with title handling in RSS, and I want to make sure that people have considered this issue) Best regards, Julian
Received on Wednesday, 18 August 2010 00:14:19 UTC