Re: Yet Another Scroll-Up Idea (YASUI) in VTT

On Sep 25, 2012, at 15:30 , Silvia Pfeiffer <silviapfeiffer1@gmail.com> wrote:

> On Wed, Sep 26, 2012 at 2:42 AM, David Singer <singer@apple.com> wrote:
>> [catching up, sorry]
>> 
>> 
>> On Sep 20, 2012, at 18:15 , Silvia Pfeiffer <silviapfeiffer1@gmail.com> wrote:
>> 
>>>> We wanted to make sure that CSS was optional and that coloring windows was possible.  Silvia has a blog started on mapping 6/708 to VTT, and in there she suggests that UAs be able to behave 'as if' a 708 style sheet were available.  We don't want two windows with the same ID but we might want two with the same color, so that suggested that the class name should be possible. (It might be good to allow zero or more class names, in fact, if we want to be able to talk about border, shadow, etc. as separate 'CSS' classes.)
>>> 
>>> I think if we wanted classes on cues or regions, we'd have to solve
>>> that more generally. I don't actually think we need class names on
>>> regions.
>>> 
>> 
>> I don't know how to enable setting regions, while enabling but not requiring, CSS, in any other way, but it sounds like you have an idea.
> 
> Yes, like Simon I would also suggest to do that with a ::cue-region()
> pseudo selector where you name the id of the region you are trying to
> style.

But that requires a style-sheet and CSS support, which I don't want to do.  Doesn't it?

The .syntax allows for a UA that effectively has your 708 style-sheet 'built-in' (i.e. does not have a true CSS implementation).

> 
> 
>> On Sep 21, 2012, at 2:02 , Silvia Pfeiffer <silviapfeiffer1@gmail.com> wrote:
>> 
>>>> Are offline players not willing to implement support for the CSS subset that
>>>> applies to WebVTT?
>>> 
>>> I can't answer that question, since I can't speak for offline players.
>>> I do know that I got push-back at VDD. Maybe JB has more to say on
>>> this.
>> 
>> We just posted <http://tools.ietf.org/html/draft-pantos-http-live-streaming-09> where we document VTT support in HTTP Live Streaming, and no, we don't require any kind of CSS support in an HLS client (and would prefer it to remain that way).  Nor do we have access to CSS in our current client, as far as I know.
> 
> When you say "current client", do you mean WebKit or a QuickTime player?

I mean our current HLS client.

> 
> So, are you saying that ::cue formatting and classes on <c> elements
> in WebVTT are not supported in your HLS player? So you are essentially
> only supporting plain text and the <b>,<i>,<u> markup? Is that because
> it's too complicated?

Right.  We don't have access to a CSS implementation, and we're hesitant to start pulling on the spaghetti-web of CSS to implement 'only the bits needed' because we have a strong suspicion that by the time we've implemented parsing, cascading, and cross-dependency of features, we'll have most of the spaghetti in our lap.

> 
> 
>> On Sep 21, 2012, at 3:08 , Simon Pieters <simonp@opera.com> wrote:
>> 
>>> 
>>> I'm getting mixed messages. On the one hand, you say that players should support the full spec. On the other hand, the style sheet is only for Web browsers?
>>> 
>> 
>> 
>> I think that the full spec. should enable use of CSS when it's offered by the author and supported by the client, but not require it.  I also think that some UAs can behave 'as if' they have a CSS style sheet built-in (e.g. one supporting 608/708 features).
> 
> 
> That's how I saw it, too. Is that how you are planning to work with
> WebVTT in HLS? Or is your HLS player just the first step towards a
> more complete support of WebVTT? I am trying to find out if there are
> fundamental issues that can't be overcome easily or if it's just a
> step-wise implementation.

I think that this is a desirable goal: players that behave as if they have some style-sheet(s) built in, that are generally applicable (i.e. can be used in any VTT file).  I don't see this changing fast in off-browser players like HLS.


David Singer
Multimedia and Software Standards, Apple Inc.

Received on Tuesday, 25 September 2012 23:11:02 UTC