- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Wed, 25 Feb 2015 14:44:54 +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 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. S.
Received on Wednesday, 25 February 2015 03:45:41 UTC