This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 28470 - [WebVTT] CSS selectors are written on top of the DOM, so should match how HTML works
Summary: [WebVTT] CSS selectors are written on top of the DOM, so should match how HTM...
Status: RESOLVED FIXED
Alias: None
Product: TextTracks CG
Classification: Unclassified
Component: WebVTT (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: This bug has no owner yet - up for the taking
QA Contact: Web Media Text Tracks CG
URL:
Whiteboard: widereview
Keywords:
Depends on:
Blocks:
 
Reported: 2015-04-12 11:10 UTC by Silvia Pfeiffer
Modified: 2016-03-02 13:30 UTC (History)
5 users (show)

See Also:


Attachments

Description Silvia Pfeiffer 2015-04-12 11:10:01 UTC
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?)
Comment 1 Silvia Pfeiffer 2015-04-12 11:17:56 UTC
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?
Comment 2 Philip Jägenstedt 2015-04-15 09:17:49 UTC
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.
Comment 3 Simon Pieters 2015-04-21 10:41:46 UTC
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.
Comment 4 Silvia Pfeiffer 2015-06-07 07:30:57 UTC
(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.
Comment 5 Silvia Pfeiffer 2015-06-07 07:45:46 UTC
https://github.com/w3c/webvtt/pull/193
Comment 6 Philip Jägenstedt 2015-06-08 11:56:33 UTC
https://github.com/w3c/webvtt/pull/193 is merged, is that all we need to do for this bug?