- From: Eric Carlson <eric.carlson@apple.com>
- Date: Wed, 25 Feb 2015 09:06:55 -0800
- To: Philip Jägenstedt <philipj@opera.com>
- Cc: Silvia Pfeiffer <silviapfeiffer1@gmail.com>, Fredrik Söderquist <fs@opera.com>, 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 Feb 24, 2015, at 9:19 PM, 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? > > Eric, what about WebKit? > Yes, we are interested. eric
Received on Wednesday, 25 February 2015 17:07:32 UTC