- From: Loretta Guarino Reid <lorettaguarino@google.com>
- Date: Wed, 21 Jan 2015 22:16:42 -0800
- To: Simon Pieters <simonp@opera.com>
- Cc: John Foliot <john@foliot.ca>, Jeroen Wijering <jeroen@jwplayer.com>, David Singer <singer@apple.com>, Steve Heffernan <steve@zencoder.com>, John Luther <jluther@jwplayer.com>, Philip Jägenstedt <philipj@opera.com>, "public-texttracks@w3.org" <public-texttracks@w3.org>, Richard Eyre <rick.eyre@hotmail.com>, Gary Katsevman <gkatsevman@brightcove.com>
- Message-ID: <CAHu5OWaqCHkqZ+JBELNtEgD=easOFDtXnYcLYC1JDg8QAqgu_w@mail.gmail.com>
On Wednesday, January 21, 2015, Simon Pieters <simonp@opera.com> wrote: > 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. This does not solve the problem of keeping all of the authored information in a single file. I agree with Jeroen on the desirability of style rules in the header. Loretta Guarino Reid Google > -- > Simon Pieters > Opera Software > >
Received on Thursday, 22 January 2015 06:17:09 UTC