28470 2015-04-12 11:10:01 +0000 [WebVTT] CSS selectors are written on top of the DOM, so should match how HTML works 2016-03-02 13:30:20 +0000 1 1 1 Unclassified TextTracks CG WebVTT unspecified PC All RESOLVED FIXED widereview P2 normal --- 1 silviapfeiffer1 dave.null nigel.megitt philipj silviapfeiffer1 singer zcorpan public-texttracks oldest_to_newest 119445 0 silviapfeiffer1 2015-04-12 11:10:01 +0000 Feedback by the CSS WG, see http://lists.w3.org/Archives/Public/public-tt/2015Apr/0007.html The list in section 5.5 (http://dev.w3.org/html5/webvtt/#webvtt-cue-text-dom-construction-rules) 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?) 119448 1 silviapfeiffer1 2015-04-12 11:17:56 +0000 Further feedback by CSS WG: 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? 119524 2 philipj 2015-04-15 09:17:49 +0000 Section 5.5 is only used for VTTCue.getCueAsHTML(), for the purposes of rendering there are no HTML elements involved. However, as actually implemented some equivalent DOM is created. In Blink there's VTTElement and I'm sure other engines have some kind of internal representation. 119719 3 zcorpan 2015-04-21 10:41:46 +0000 We could define a WebVTT DOM but that is strictly speaking an editorial issue, the black-box behavior should be the same. In either case, it can be implemented with DOM or with some other representation. We could add some non-normative text to the DOM construction section saying that the rules are for getCueAsHTML(), not for rendering. 120775 4 silviapfeiffer1 2015-06-07 07:30:57 +0000 (In reply to Simon Pieters from comment #3) > We could define a WebVTT DOM but that is strictly speaking an editorial > issue, the black-box behavior should be the same. In either case, it can be > implemented with DOM or with some other representation. I'd prefer we leave it as generic as possible. That way, non-browser video players might find it useful, too. > We could add some non-normative text to the DOM construction section saying > that the rules are for getCueAsHTML(), not for rendering. I'll prepare a PR for this. 120776 5 silviapfeiffer1 2015-06-07 07:45:46 +0000 https://github.com/w3c/webvtt/pull/193 120806 6 philipj 2015-06-08 11:56:33 +0000 https://github.com/w3c/webvtt/pull/193 is merged, is that all we need to do for this bug?