Re: VTT/CSS (was RE: Evidence of 'Wide Review' needed for VTT)

On Wed, 21 Jan 2015 17:27:25 +0100, Jeroen Wijering <jeroen@jwplayer.com>  
wrote:

> Hey David, John,
>
>>> when you say inline CSS, you mean both of
>>> a) style-sheets in the header?
>>> b) styling in the cues themselves, using CSS snippets?
>>>
>>> Have you looked at the old threads on this question?  I think we got
>>> close to a number of possible designs, but held off until it was really
>>> needed and we had real implementers on hand.
>
> Style rules in the header are most important IMO. They allow CC
> authors to style:
>
> *) All cues in a VTT
> *) Specific cues (using classes or ids)
> *) Specific persons or snippets (using voices or ids)
>
> I see inline styling as largely redundant to styling rules in the
> header (most can be achieved with classes, id's and voices).
>
>> This should be achievable through UA configuration or even through  
>> something
>> like a greasemonkey script or user CSS which can override styles  
>> dynamically
>> in the browser."
>> (source: Media Accessibility User Requirements -
>> http://www.w3.org/WAI/PF/media-a11y-reqs/#VP-2)
>>
>> From a practical perspective, it is significantly easier for third  
>> parties to
>> write scripts and/or user style-sheets if the content is all located in
>> one-place. For this reason, I would suggest that CSS be contained in a  
>> linked
>> style sheet, and *NOT* written in-line in the VTT file.
>
> This is absolutely important, but I also see this also as a separate
> step. Overall there seem to be 3 tiers:
>
> First, there's the styling rules from the environment (HTML5 browser),
> which apply to all VTT files played. They're the baseline. General use
> cases are to make the captions look good and read well within the
> site/player design.
>
> Second, there's the styling from the VTT author, which apply to only
> that single file. Use cases include emphasis on certain types of cues
> (music, voiceover, etc) and certain ranges of cues (e.g. repositioning
> when the default region overlaps with in-video text).

VTT doesn't allow CSS to reposition cues, other than by changing the  
line-height.

> It's preferred
> to have these rules live inside the VTT, as it makes for easier
> authoring, file management, conversion to other formats and
> implementation of parsers (outside of HTML browsers).
>
> Third, the end user can override the styles an author has set (or,
> more common, set additional rules). This is specific to the individual
> user and relates to the FCC options end users can set in video
> players. As David said, through CSS but more importantly system-wide
> menus (iOS/Android/etc) or options in the video player
> (YouTube/JWPlayer/etc).
>
> In short, style rules in the header of a VTT file is what we (our
> publishers) would like to have. Styling rules inside the cues and
> links to external CSS are less relevant.

CSS can link to external CSS with @import, so VTT doesn't need a dedicated  
mechanism for that.

-- 
Simon Pieters
Opera Software

Received on Thursday, 22 January 2015 05:58:16 UTC