User Agent: Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.64 Safari/537.31 Steps to reproduce: The :future and :past pseudo-elements need to be implemented so that anonymous content created by the WEBVTT parser, relating to captions that are in the immediate past or future of the current caption displaying, can be accessed through it. See: http://dev.w3.org/html5/webvtt/#the-past-and-future-pseudo-classes
Summary: Implement :past and :future pseudo-element → Implement :past and :future pseudo-classes
Pseudo-classes are pretty easy to implement (unlike pseudo-elements; the distinction is important).
Though it's not clear to me whether these WebVTT nodes are DOM nodes... perhaps whether they are or not is an implementation detail, in which case we can just make them so and then I agree: pseudo-classes are easy.
As far as I can tell they should be. See: http://dev.w3.org/html5/webvtt/#webvtt-cue-text-dom-construction-rules.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → WONTFIX
Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: WONTFIX → ---
Component: Audio/Video → Audio/Video: Playback
This should be related to layout.
Component: Audio/Video: Playback → Layout
From email by :heycam : To support these I think we just need to: (a) add two #defines NS_EVENT_STATE_* entries in dom/events/EventStates.h for past and future (b) add entries in nsCSSPseudoClassList.h using CSS_STATE_PSEUDO_CLASS that references these two NS_EVENT_STATE_* values (c) when you need to update which nodes in your DOM tree match these pseudo-classes, you need to call the C++ functions Element::AddStates(NS_EVENT_STATE_*) and Element::RemoveStates(NS_EVENT_STATE_*) to set and clear these state bits, but since you're in JS you might want to add a function to nsIDOMWindowUtils that calls into Element::AddStates/RemoveStates
Assignee: nobody → bechen
AddStates/RemoveStates are for use from the ESM only. That's why they're protected and have assertions about the set of states passed to them. That said, we could do some renaming (e.g. ESM_MANAGED_STATES to EXTERNALLY_MANAGED_STATES) and allow whatever API we're talking about here to call Add/RemoveStates. If we do that, you will be taking over management of these states completely, including for cases like node removal from the document, adoption into another document, etc (assuming that can happen for the relevant nodes). That all said, depending on how many of these nodes you have and whether the perf/memory overhead is acceptable, you may be able to use inIDOMUtils.addPseudoClassLock to do this.
(In reply to Boris Zbarsky [:bz] (still a bit busy) from comment #6) > AddStates/RemoveStates are for use from the ESM only. That's why they're > protected and have assertions about the set of states passed to them. > > That said, we could do some renaming (e.g. ESM_MANAGED_STATES to > EXTERNALLY_MANAGED_STATES) and allow whatever API we're talking about here > to call Add/RemoveStates. Ah, indeed, I missed that we'd need to add them to ESM_MANAGED_STATES. > If we do that, you will be taking over management of these states > completely, including for cases like node removal from the document, > adoption into another document, etc (assuming that can happen for the > relevant nodes). These are NAC nodes that will be controlled entirely from within webvtt.jsm, so I don't think we need to handle such cases. > That all said, depending on how many of these nodes you have and whether the > perf/memory overhead is acceptable, you may be able to use > inIDOMUtils.addPseudoClassLock to do this. Hmm, my initial thought was to suggest this, but then I realised that this would preclude devtools locking these state bits. (Which may or not be something they'd want to do.)
Ah, good point. If devtools can examine these nodes (can they?) then I agree we shouldn't stomp on their API.
I don't know the answer to that, but it seems plausible that it would be useful for developers producing WebVTT files to be able to inspect the stylable captions that we show.
FYI, Chrome supports :past and :future, here is the test case, https://people-mozilla.org/~alwu/WebVTT/vttTest.html
You need to log in before you can comment on or make changes to this bug.