Re: In-file style sheets for VTT, discussion

Hi Thierry, everyone, thanks

> On Mar 11, 2015, at 0:30 , Thierry MICHEL <tmichel@w3.org> wrote:
> 
> 
> We may have other requests from the accessibility, I18N folks before going to CR. Let's wait for the wide review from the groups for which the TTWG has dependencies with.

Yes, of course we want their input on the current draft. Do you know when they hope to have it by?

> For the styling in WebVTT, the major use case I see is that currently a WebVTT can be only styled in an HTML browser media player (the CCS style being declared in the HTML hosting page).
> Therefore a WebVTT file can not be played styled in a none HTML Media player.
> To allow this, adding CSS styling within WebVTT file would satisfy that need. Web browsers could also parse WebVTT file styling.
> 
> 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…)

Well, on the face of it it’s actually a user-agent feature over how they allow the user to supply user-side style sheets or other styling guidance or over-rides. However, if the content can be styled intrinsically, it’s more likely to have ‘useful’ classes linked to the cues, and hence there is greater latitude for user styling.

> 
> On Mar 11, 2015, at 4:09 , Silvia Pfeiffer <silviapfeiffer1@gmail.com> wrote:
> 
>> 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.
> 
> 

I suggest we discuss process and desirability questions on the mailing lists, and detailed technical comments on the design etc. in the bug tracker.  But of course either kind of comment is welcome everywhere; it just makes it easier to know that, when looking at the bug, you’re probably seeing most if not all of the comments on the design.

> On Mar 11, 2015, at 4:32 , Nigel Megitt <nigel.megitt@bbc.co.uk> wrote:
> 
> 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.
> 

Right.  In streaming systems one can sometimes say “here is a new set of initialization data” (e.g. a new sample entry in an MP4 file), so the first two get covered by that.  Yes, the third is fine, as that style is literally inline.

What we want to avoid is having new styles introduced at arbitrary points, that then persist to the end of the file.  It kills random access.


David Singer
Manager, Software Standards, Apple Inc.

Received on Wednesday, 11 March 2015 21:41:43 UTC