W3C home > Mailing lists > Public > public-texttracks@w3.org > September 2012

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

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Wed, 26 Sep 2012 09:52:43 +1000
Message-ID: <CAHp8n2nObeYAZNs8W-tW6hiZbXEqJNT1KOTDQ1+gUFAnUVWrLQ@mail.gmail.com>
To: David Singer <singer@apple.com>
Cc: public-texttracks <public-texttracks@w3.org>
On Wed, Sep 26, 2012 at 8:35 AM, David Singer <singer@apple.com> wrote:
>
> 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).

I see. Let me think about that. I'm going to have to include that into
the 608/708 doc anyway. I'll try and update it with the spec at
http://www.w3.org/community/texttracks/wiki/MultiCueBox and see how
far I get.


>>> 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.


That's the same argument I heard from VLC.


>>> 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.

So they would likely follow the 608/708 spec?

Cheers,
Silvia.
Received on Tuesday, 25 September 2012 23:53:31 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 8 May 2014 13:18:52 UTC