- From: Simon Pieters <simonp@opera.com>
- Date: Thu, 19 Feb 2015 09:06:35 +0400
- To: "www-style@w3.org" <www-style@w3.org>
- Cc: "Tab Atkins Jr." <jackalmage@gmail.com>
(Gathering CSSWG feedback on the wrong list; forwarding to www-style.) ------- Forwarded message ------- From: "Simon Pieters" <simonp@opera.com> To: "Bert Bos" <bert@w3.org>, "Tab Atkins Jr." <jackalmage@gmail.com> Cc: "CSS WG mailing list" <w3c-css-wg@w3.org> Subject: Re: Agenda+ review 1st WD of WebVTT Date: Wed, 18 Feb 2015 08:34:57 +0400 (Not replying on behalf of the Timed Text WG here.) On Wed, 18 Feb 2015 01:24:36 +0400, Tab Atkins Jr. <jackalmage@gmail.com> wrote: > Section 5.5 > * Why are these all HTMLElement? Why not the appropriate HTMLElement > subclass? HTMLElement is the appropriate interface for given elements. See the HTML spec. > * This list 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. Yes. Also the namespace is different. Also the root node is a document fragment here but a no-name element for Selectors. This is intentional, IIRC to avoid non-browser implementations to support the DOM. > Selectors is written on top of the DOM, though, so these should match. Why? The DOM construction rules are used for converting WebVTT to HTML with getCueAsHTML(), not for rendering WebVTT. > * Related to the previous, this section seems incomplete. It doesn't > apply classes, Yes it does: "if the corresponding WebVTT Internal Node Object has any applicable classes, must have a class attribute set to the string obtained by concatenating all those classes, each separated from the next by a single U+0020 SPACE character." > attributes, "WebVTT Voice Object HTMLElement element node with localName "span", and a title attribute set to the WebVTT Voice Object's value. WebVTT Language Object HTMLElement element node with localName "span", and a lang attribute set to the WebVTT Language Object's applicable language." > or IDs, Only cues/regions can have IDs, not WebVTT nodes. > but the later Selectors section > defines all of these. > > Section 6.2.3.1 > * "group of selectors" has no defined meaning. You probably want > either "compound selector list" or "complex selector list". > * 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. If we're going to use a DOM for rendering, there's no reason to define "WebVTT nodes" with a mapping to DOM at all, the WebVTT parser can create the DOM directly. > 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. > * 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 I guess the background property would apply over a wider box. > > > Regarding external stylesheets, I don't recommend trying to use sheets > from the outer document (except insofar as the outer document uses > ::cue(), obviously). Only ::cue() et al from the document are defined to match anything in WebVTT. What is the problem? > Can WebVTT be extended to ref an external > stylesheet? I think this is planned. -- Simon Pieters Opera Software
Received on Thursday, 19 February 2015 08:07:04 UTC