- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Thu, 27 Sep 2012 11:26:05 +1000
- To: David Singer <singer@apple.com>
- Cc: Simon Pieters <simonp@opera.com>, public-texttracks <public-texttracks@w3.org>
On Thu, Sep 27, 2012 at 8:45 AM, David Singer <singer@apple.com> wrote: > > On Sep 26, 2012, at 0:40 , Simon Pieters <simonp@opera.com> wrote: > >> On Tue, 25 Sep 2012 23:54:48 +0200, David Singer <singer@apple.com> wrote: >> >>> >>> On Sep 24, 2012, at 7:28 , Silvia Pfeiffer <silviapfeiffer1@gmail.com> wrote: >>> >>>> >>>> In any case: I'm going to use file-wide metadata for the CEA-608/708 >>>> conversion document [1]. I'm going to follow what was last discussed >>>> with Simon, except I don't really know when to end the multi-line >>>> value, so I chose a random "##" as the character sequence to end it >>>> (happy for any better suggestions). I preferred this as more obvious >>>> than a single ".". >>> >>> roughly why I suggested [[ to open and ]] to close (it's more visually noticeable, and is like CDATA) :-). Not a ditch worth dying in, as long as we choose a line that is unlikely in what we want to embed (notably CSS). >>> >>> >>>> I'm fully aware that the WebVTT spec itself needs not to say anything >>>> about this - it will not break browsers in any case. It would, >>>> however, be better if we could change the spec to regard the >>>> multi-line values that may have empty lines in them not as broken >>>> cues, but as part of the header. We could define - as Simon said - >>>> anything between the "WEBVTT" magic string and the first successfully >>>> parsed cue as "header". >>> >>> >>> ...or we could ban blank lines in the header (none of our use-cases require them, after all), or escape them (or a combination). >> >> If the use cases don't require blank lines, we can use a blank line to end a multi-line header. > > ouch. can we use the blank line, as now, to end the headers? > > you seem to want to make it possible to mix headers and cues, which means we have to have a more complex way to tell them apart, and rules not to put headers after cues, and I am not sure at all why. can you explain? I thought we had agreed that we wanted to allow blank lines in multi-line metadata values (in particular to more nicely format CSS styles). Thus, a blank line shouldn't end the headers, but instead the first validly parsed cue should. Silvia.
Received on Thursday, 27 September 2012 01:26:52 UTC