- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Tue, 24 Apr 2012 11:08:38 +1000
- To: David Singer <singer@apple.com>
- Cc: Glenn Maynard <glenn@zewt.org>, public-texttracks@w3.org
On Tue, Apr 24, 2012 at 10:59 AM, David Singer <singer@apple.com> wrote: > > On Apr 23, 2012, at 17:46 , Silvia Pfeiffer wrote: > >>> Yes. Then all we need to add is >>> "In multi-line values, a line that either (a) starts with the escape >>> character >> >> There is no escape character. I don't think we need one. > > You absolutely need one. Otherwise neither value lines consisting of "." nor blank lines are possible. True. >>> or (b) is blank (safer, visually blank) >> >> We can't do blank lines or we break the WEBVTT parsing algorithm. I >> think we will have to just accept that WebVTT headers can't have blank >> lines. > > No, I am saying that *input* blank lines are escaped so they are no longer blank so the VTT parsing does NOT fail. Forbidding blank value lines is too restrictive. I could probably live without "." lines (but even SMTP handles this). OK. I guess I'm ok with "\" as the escape character. >>> If we want total flexibility, remove the line-break before the "." line, so >>> you can end without the line-end character if you want to (you can always >>> put it back explicitly with an escaped blank line). >> >> I think that's not so easy to parse and visually see as just "." on a >> line by itself. And it's easy to forget it at the end of a line, so >> I'd rather just have it there on a line by itself. > > No, you're missing me. > > Glenn's example: >> Key: | >> Value >> . >> >> Key: | >> | >> . > > These both have a value that has a final line-end character. So > > Key: * > has a one-character value, and > Key: | > | > . > has a two-character (|\n) value. This is fixable; the termination is the string "\n.\n" and it's all removed. If you want a final \n, put it in specifically (escaped). Yeah, I think that the BNF that I suggested did that. But then, BNFs are hard to read, so indeed that was the intention. :-) Cheers, Silvia.
Received on Tuesday, 24 April 2012 01:09:27 UTC