- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Wed, 25 Feb 2015 15:07:46 +1100
- To: Philip Jägenstedt <philipj@opera.com>
- Cc: David Singer <singer@apple.com>, John Luther <jluther@jwplayer.com>, Rick Eyre <rick.eyre@hotmail.com>, "public-texttracks@w3.org" <public-texttracks@w3.org>, Gary Katsevman <gkatsevman@brightcove.com>, Steve Heffernan <steve@zencoder.com>, Jeroen Wijering <jeroen@jwplayer.com>
On Wed, Feb 25, 2015 at 3:04 PM, Philip Jägenstedt <philipj@opera.com> wrote: > On Wed, Feb 25, 2015 at 10:44 AM, Silvia Pfeiffer > <silviapfeiffer1@gmail.com> wrote: >> On Wed, Feb 25, 2015 at 1:57 PM, Philip Jägenstedt <philipj@opera.com> wrote: >>> On Tue, Feb 24, 2015 at 4:50 AM, Silvia Pfeiffer >>> <silviapfeiffer1@gmail.com> wrote: >>>> Hi David, >>>> >>>> On 24 Feb 2015 06:46, "David Singer" <singer@apple.com> wrote: >>>>> >>>>> >>>>> > On Feb 21, 2015, at 23:10 , Silvia Pfeiffer <silviapfeiffer1@gmail.com> >>>>> > wrote: >>>>> > >>>>> > Note that I have made a new suggestion as to how to deal with inline >>>>> > styles in VTT. >>>>> > https://www.w3.org/Bugs/Public/show_bug.cgi?id=15023#c15 >>>>> > >>>>> > If that is agreeable and it is a requirement to be added before we go >>>>> > to CR, I can write the spec for that (assuming Philip agrees with the >>>>> > proposed approach). >>>>> >>>>> we had a long discussion on this several years back. I’ll try to >>>>> resurrect the questions >>>>> >>>>> 1) can new styles occur only in the header, or throughout the file? >>>>> I commented on the bug: currently VTT files are beautifully incremental >>>>> and random accessible; allowing styles to occur anywhere and persist to end >>>>> of file would badly impact that. Can we do the 90%+ case and have styles >>>>> only at the beginning, please? I don’t mind if they are ‘part of’ the >>>>> header or just after it and before the first cue. >>>> >>>> The advantage of making this a block is that we can define both types. If >>>> the block is used at the beginning, it is valid for the whole file. If the >>>> block appears at a later stage, it replaces the previous definitions (or >>>> just adds to them). We could even make style blocks that are valid for a >>>> certain time interval, just like cues. I'd regard that as a v2 feature, but >>>> it's certainly easier to add than extending a metadata header. >>>> >>>>> 2) What about multi-line? We either need a syntax that allows blank >>>>> lines, or an escape for them. Years back, we suggested escape. But removing >>>>> blank lines is as easy as escaping them, and has the huge advantage that the >>>>> result is still valid CSS. >>>> >>>> Philip asked about multi line in the bug too. With a block, multi line comes >>>> naturally. Blank lines could then either be removed or replaced by a control >>>> character. We don't have to come up with special cases for multi line if we >>>> choose a block. It's another advantage over the meta header. >>>> >>>>> What other basic design choices are there, that we could debate? >>>> >>>> That's it really. Let me know what you think. >>> >>> I think I agree with Silvia here, a STYLE block seems more natural >>> than putting it in the header. Note that we could still, if there are >>> strong reasons, drop any such blocks that come after any cue. It gives >>> us some flexibility with the streaming case, even if we don't use it >>> now. >> >> I understand David's concern, too, and agree that we could drop STYLE >> blocks that come after the first cue. We could in future require such >> later STYLE blocks to be timed, so they actually express which cues >> they apply to. >> >>> I'm not sure about multi-line though, that doesn't seem to be made any >>> simpler by using a block, unless a STYLE block should continue until >>> the next valid block is found. I think that would be a little >>> unfortunate, it would make STYLE blocks different from NOTE blocks and >>> could make it hard to introduce new blocks that come after STYLE. >> >> Multiline is simpler as a block because we don't currently have a >> mechanism for multiline header metadata. The only issue is blank >> lines. I think we just take it easy and require STYLE blocks to not >> have blank lines. If somebody wants to retain the blank lines, they >> just have to re-start the STYLE block. > > Sorry, I was confused, thinking only of blank lines. You're right that > multiple lines are simple in a block but not so simple in a key-value > header structure. I would be happy to not allow blank lines, since I > don't know how to solve it anyway. Sounds to me like we got to an agreement? S.
Received on Wednesday, 25 February 2015 04:08:34 UTC