- From: Fredrik Söderquist <fs@opera.com>
- Date: Wed, 25 Feb 2015 11:09:25 +0100
- To: "Silvia Pfeiffer" <silviapfeiffer1@gmail.com>, "Eric Carlson" <eric.carlson@apple.com>, 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, 25 Feb 2015 06:19:38 +0100, Philip Jägenstedt <philipj@opera.com> wrote: > On Wed, Feb 25, 2015 at 11:07 AM, Silvia Pfeiffer > <silviapfeiffer1@gmail.com> wrote: >> 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? > > Yes, essentially it's the very first suggestion in > https://www.w3.org/Bugs/Public/show_bug.cgi?id=15023#c0 > > The question is if there is implementor interest. > > Fredrik, would you be interested in this in Blink? Not something I would jump on immediately. /fs -- Using Opera's mail client: http://www.opera.com/mail/
Received on Wednesday, 25 February 2015 10:09:57 UTC