- From: David Singer <singer@apple.com>
- Date: Thu, 09 Apr 2015 08:50:29 -0700
- To: public-texttracks@w3.org
FYI. I am suggesting that, as usual, the editors do the initial triage, filing bugs etc. > Begin forwarded message: > > From: Bert Bos <bert@w3.org> > To: public-tt@w3.org > Date: April 9, 2015 at 02:21:22 PDT > Subject: [webvtt] comments from the CSS WG on WD-webvtt1-20141111 > Archived-At: <http://www.w3.org/mid/201504091121.31788.bert@w3.org> > Resent-From: public-tt@w3.org > > The CSS WG looked at the first draft of webvtt and these are the comments we > came up with: > > 1) The example in section 1.1 is possibly a use case for a new property and > keyword for CSS, tentatively called 'text-wrap: balance', whose goals are to > avoid that the last line of a paragraph is much shorter than the other > lines. (The property appeared in an example in a WD once, but no definition > has been published yet). > > 1a) Further investigation may be needed to see if and how this balancing > (and the CSS property) applies to different scripts. > > 1b) And if the WebVTT use case and the CSS property are indeed the same > feature, we'll need to see how precisely we want to define it: is it a good > idea to specify a formula? (E.g., minimize a function that adds up a number > of things like the total number of lines, the (absolute value or square of) > each line's difference from the mean length, each line's difference from the > available width, each line's difference from the previous line, each space's > difference from the normal space width, the difference between the amount of > stretching/shrinking in each line's spaces compared to the previous line, > the difference in the amount of letter spacing in each line compared to the > previous line, the occurrences of "rivers", etc.); or is it better to just > give hints about possible factors to take into account and leave room for > implementations to do better (but slower) or worse (but faster)? > > 2) Section 5.5: Some people wonder if HTMLElement is the right type to use > for all the nodes, or if it is better to use more specific subclasses. > > 3) The list in that section doesn't match with the description of how > Selectors work; in particularly, Class, Voice, and Lang objects are all > "span" elements here, but are "c", "v", and "lang" elements in Selectors. > Selectors is written on top of the DOM, though, so these should match. (But > we hear this difference is intentional?) > > 4) Related to the previous, this section doesn't seem to apply the IDs of > region objects. > > 5) Section 6.2.3.1: "group of selectors" has no defined meaning. You > probably want either "compound selector list" or "complex selector list". > > 6) You can remove the entire section about how to evaluate the selector > once section 5.5 defines an accurate DOM mapping; just specify that it > matches over the equivalent DOM defined in 5.5. Or are there (intentional) > differences between selecting against a WebVTT DOM and the mapped HTML DOM? > > 7) Section 6.2.3.3: It looks like cue regions are basically blocks that get > filled with cues. Why not just make those an element selectable by ::cue()? > You're limited to the same styles that apply to ::cue anyway. > > 8) Even though regions have an ID, it looks like you can't select by > it. All you can do is apply styles to all regions. What's the > purpose of this, then? It seems equivalent to ::cue with no argument, > except maybe the background property would apply over a wider box. > > 9) Regarding external stylesheets, several people recommend against trying > to use sheets from the outer document (except for style rules that use > ::cue()). Can WebVTT be extended to ref an external stylesheet? > > > > For the CSS WG, > Bert > -- > Bert Bos ( W 3 C ) http://www.w3.org/ > http://www.w3.org/people/bos W3C/ERCIM > bert@w3.org 2004 Rt des Lucioles / BP 93 > +33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France David Singer Manager, Software Standards, Apple Inc.
Received on Thursday, 9 April 2015 15:51:04 UTC