RE: In-file style sheets for VTT, discussion

"it’s more likely to have ‘useful’ classes linked to the cues"
+1

This is a key aspect to user driven styling - and an aspect that could significantly benefit from standardisation effort.

Regards,
John

John Birch | Strategic Partnerships Manager | Screen
Main Line : +44 1473 831700 | Ext : 2208 | Direct Dial : +44 1473 834532
Mobile : +44 7919 558380 | Fax : +44 1473 830078
John.Birch@screensystems.tv | www.screensystems.tv | https://twitter.com/screensystems


Visit us at
NAB, Las Vegas Convention Center 13-16 April 2015 Stand No. SU9610

P Before printing, think about the environment-----Original Message-----
From: David Singer [mailto:singer@apple.com]
Sent: 11 March 2015 21:41
To: Thierry MICHEL
Cc: public-texttracks@w3.org; TTWG
Subject: 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.



This message may contain confidential and/or privileged information. If you are not the intended recipient you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. Screen Subtitling Systems Ltd. Registered in England No. 2596832. Registered Office: The Old Rectory, Claydon Church Lane, Claydon, Ipswich, Suffolk, IP6 0EQ

Received on Thursday, 12 March 2015 08:40:01 UTC