W3C home > Mailing lists > Public > public-tt@w3.org > March 2015

Re: In-file style sheets for VTT, discussion

From: Nigel Megitt <nigel.megitt@bbc.co.uk>
Date: Wed, 11 Mar 2015 11:32:02 +0000
To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>, Thierry MICHEL <tmichel@w3.org>
CC: Public TTWG List <public-tt@w3.org>, "public-texttracks@w3.org" <public-texttracks@w3.org>, David Singer <singer@apple.com>
Message-ID: <D125D377.1C9AE%nigel.megitt@bbc.co.uk>
(Top posting as this doesn’t relate directly to any single comment in the
thread)

If you consider the live production use case and assume* that the
streaming model is to continually append to the VTT file then styling new
cues by cue ids related to styles in a single style block in the header
doesn't work in the general case. Accepted that in VTT there's no
uniqueness constraint on cue ids, but if the author decides mid stream to
create a cue with a brand new style then it seems to me that the options
are:

1) replace the style block;
2) add to the style block;
3) apply styling inline.

The situation for region based positioning is analogous, by the way.

This is orthogonal to user agent based styling overrides.

* If the starting assumption doesn't hold and the streaming model is to
send new whole VTT documents then having a single style block in the
header is fine of course.

Nigel


On 11/03/2015 11:09, "Silvia Pfeiffer" <silviapfeiffer1@gmail.com> wrote:

>On Wed, Mar 11, 2015 at 9:41 PM, Thierry MICHEL <tmichel@w3.org> wrote:
>>
>>
>> On 11/03/2015 09:47, Silvia Pfeiffer wrote:
>>>
>>>
>>> On 11 Mar 2015 18:31, "Thierry MICHEL" <tmichel@w3.org
>>> <mailto:tmichel@w3.org>> wrote:
>>
>>
>>>  > To allow this, adding CSS styling within WebVTT file would satisfy
>>> that need. Web browsers could also parse WebVTT file styling.
>>>  >
>>>
>>> Yes, that's a good summary of the motivation for this feature.
>>>
>>>  > Also providing a CSS styling within WebVTT file resolves some
>>> accessibilities issues, if the users needs to change the default
>>>styling
>>> (bigger fonts, diffrent colors, etc...)
>>>  >
>>>
>>> Not really, because such styling would be supplied power user through
>>> browser settings so they would overrule CSS styling.
>>
>>
>> Yes I agree that browser settings would work in an HTML browser Player.
>>But
>> that does not work in a non HTML Media Player.
>
>
>Wouldn't a media player also have default settings specific for the
>user? This styling is for the author to provide, so I don't see how
>that can satisfy all the different accessibility use cases.
>
>
>> The issue is do we want to have a text track format that only palys in
>>Web
>> Browsers, or do we want also to adress playing WebVTT files in regular
>>Media
>> player.
>>
>> Currently SRT can be played in regular Media player. I would hope that
>> WebVTT does the same with its improved capabilities.
>
>Agreed.
>
>>>
>>>  > CSS stylings in the WebVTT file can be done as follows:
>>>  >
>>>  > 1-In the Header:
>>>  >
>>>  > 1.1- Import a CSS style sheet:
>>>  >     Style:
>>>  >       @import(cea608.css)
>>>  >     ##
>>>  >
>>>  > 1.2- In a  CSS style declaration section:
>>>  >     WEBVTT
>>>  >       Style:
>>>  >       ::cue(v[voice=Bob]) {color:green;}
>>>  >       ::cue(c.question) {font-style:italic;}
>>>  >     ##
>>>  >
>>>
>>> There's a bit more detail in the bug that David referenced. Again: if
>>> there are technical concerns, I would encourage discussion to continue
>>> in the bug, so it status together as much as possible.
>>
>>
>> Yes I know it is recorded in the bug tracker, but maybe the TTWG wants
>>also
>> to discuss this.
>
>I would absolutely encourage this. We just don't want to have repeat
>technical arguments. The bug tracker is accessible to everybody, so
>should not restrict anyone in the TTWG from contributing there.
>
>
>>>  > 2- Inline styling (throughout the WebVTT file not just in the header
>>> of a WebVTT file). Possibly even scoped for individual cues -
>>>
>>> This use case was rejected by Apple, so as to avoid having to keep
>>>track
>>> of such temporary changes during the duration of the video and enable
>>> direct access ability, in particular in in-band or hls used of WebVTT.
>>
>>
>> OK, I also agree that this feature isn't a must.
>>>
>>>
>>> I think that's fair, since we have this:
>>>
>>>  > Note: Currently there is support per-cue styling via cue IDs (but
>>>not
>>> yet implemented).
>>>  >     <style>  ::cue(#myid) {font-style : italic;}  </style>
>>>
>>> It's implemented in chrome and safari, just not in Firefox or IE.
>>
>>
>>
>> Wel I tried it on Chrome Version 38.0.2125.111 m
>> The following code does not work
>> in the HTML page:
>>  ::cue(#c11)       {color:yellow;}
>>
>> in the WebVTT file:
>> c11
>> 00:00:51.000 --> 00:00:55.000
>> This cue has a unique id.
>> Using CSS, its font color should be yellow.
>>
>> I also tried it on Safari on my Ipad, does not work either.
>>
>> You can try it with my demo online
>> https://www.w3.org/2015/Talks/0212-WebVTT/#(25)
>
>I think you might be right. Here's another test of this:
>http://www.jwplayer.com/html5/webvtt/ .
>It seems that ::cue works, but not for addressing cues by ID.
>It's possible to do this via classes though.
>
>Cheers,
>Silvia.
>
>>
>> But maybe I am missing something ...
>>
>> Cheers,
>> Thierry
>>
>>
>

Received on Wednesday, 11 March 2015 11:32:37 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 5 October 2017 18:24:21 UTC