- From: Glenn Maynard <glenn@zewt.org>
- Date: Thu, 19 Apr 2012 17:54:32 -0500
- To: David Singer <singer@apple.com>
- Cc: Silvia Pfeiffer <silviapfeiffer1@gmail.com>, public-texttracks@w3.org
Received on Thursday, 19 April 2012 22:55:01 UTC
On Thu, Apr 19, 2012 at 3:29 AM, David Singer <singer@apple.com> wrote: > it makes style-sheets readable, and aren't line-breaks significant in > style-sheets? > > And we don't *want* actual empty lines, as simple parsers will think the > cue-text is coming next. > I guess it's worth throwing out there: it could use JSON, with the added restriction that newlines are not allowed as part of whitespace between tokens. For example: Kind: "captions" Initial-Timestamp: 1000 Style: "p { font-size: 100px; }\n.class { text-color: red; }" This has a couple advantages: values are typed, complex types can be represented (if there's any call for that; there may not be), and it handles things like newlines for us without needing to actually store them directly. It's easy to parse: each entry is a single line, and everyone already has a JSON parser for the rest of the work. The main disadvantage is that, for multiline blocks, it's cosmetically ugly. If you're editing with an editor, then this is no problem, though: it would decode the string and display it as multiline. (I could probably think up a workaround for this to allow newlines even though JSON doesn't, but that might negate the benefits, since then you couldn't read a whole header simply by reading a single line.) -- Glenn Maynard
Received on Thursday, 19 April 2012 22:55:01 UTC