- From: Philip Jägenstedt <philipj@opera.com>
- Date: Wed, 25 Feb 2015 11:04:12 +0700
- To: Silvia Pfeiffer <silviapfeiffer1@gmail.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 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. Philip
Received on Wednesday, 25 February 2015 04:04:39 UTC