- From: David Singer <singer@apple.com>
- Date: Wed, 25 Feb 2015 12:34:39 -0800
- To: Silvia Pfieffer <silviapfeiffer1@gmail.com>
- Cc: Philip Jägenstedt <philipj@opera.com>, Jeroen Wijering <jeroen@jwplayer.com>, Steve Heffernan <steve@zencoder.com>, John Luther <jluther@jwplayer.com>, "public-texttracks@w3.org" <public-texttracks@w3.org>, Richard Eyre <rick.eyre@hotmail.com>, Gary Katsevman <gkatsevman@brightcove.com>
> On Feb 24, 2015, at 21:34 , Silvia Pfeiffer <silviapfeiffer1@gmail.com> wrote: > > On Wed, Feb 25, 2015 at 3:51 PM, Philip Jägenstedt <philipj@opera.com> wrote: >> On Tue, Feb 24, 2015 at 2:46 AM, 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. >> >> I don't have a use case for allowing style anywhere and don't know if >> it matters, but what problem are you trying to avoid? Is it that a >> file is slow to parse so that the style is parsed and applied too >> late? Note that cues with early timestamps can be at the end of the >> file, so it's already possible to author a file poorly. >> >> I thought that loading text tracks would block playback start, but I >> actually can't find that in the HTML spec now. If that were the case, >> there would be no problem. >> >>> 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. >> >> Simon had an interesting idea in >> https://www.w3.org/Bugs/Public/show_bug.cgi?id=15023#c19 > > The escaping of --> is indeed something we need to deal with, too, > seeing as --> is a cue boundary mechanism in WebVTT. > > I like the idea of Simon to just treat the body of a STYLE block as > CSS and require the use of --\> for escaping -->. > > >> But unless we think this is going to be a big problem, simply not >> allowing blank lines seems like a good enough start to me. > > So, if we already have to change CSS by escaping --> , we might as > well either escape blank lines, too, or ignore them. true. I was going to say that’s one advantage of the header, but I think we terminate headers on a blank line OR a —>, so it’s not > > S. David Singer Manager, Software Standards, Apple Inc.
Received on Wednesday, 25 February 2015 20:35:10 UTC