On Tue, 04 Jan 2011 23:02:45 +0100, Glenn Maynard <[email protected]> wrote:
On Tue, Jan 4, 2011 at 4:24 AM, Philip Jägenstedt <[email protected]>
wrote:
If you need an intermediary format while editing, you can just use any
syntax you like and have the editor treat it specially.
If I'd need to write my own parser to write an editor for it, that's
one thing--but I hope I wouldn't need to create yet another ad hoc
caption format, mirroring the features of this one, just to work
around a lack of inline comments.
The cue text already vaguely resembles HTML. What about <!-- comments
-->? It's universally understood, and doesn't require any new escape
mechanisms.
<!-- comments --> in particular won't work because --> is already used in
the timing format:
00:00.000 --> 00:01.000
In any case, coming up with a syntax is not a problem, /* comments */ and
// comments like CSS/JavaScript are the most obvious choices.
The question is rather if the comments should be exposed as DOM comment
nodes in getCueAsHTML, which seems to be what you're asking for. That
would only be possible if comments were only allowed inside the cue text,
which means that you couldn't comment out entire cues, as such:
00:00.000 --> 00:01.000
one
/*
00:02.000 --> 00:03.000
two
*/
00:04.000 --> 00:05.000
three
Therefore, my thinking is that comments should be removed during parsing
and not be exposed to any layer above it.
--
Philip Jägenstedt
Core Developer
Opera Software
