Re: Inband styling (was Re: Evidence of 'Wide Review' needed for VTT)

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