865401 - Implement :past and :future pseudo-classes

Status: REOPENED

(Core :: Layout, enhancement)

Description

[Rick Eyre (:reyre)]

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

Comment 1

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Pseudo-classes are pretty easy to implement (unlike pseudo-elements; the distinction is important).

Comment 2

[Boris Zbarsky [:bzbarsky]]

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.

Comment 3

[Rick Eyre (:reyre)]

As far as I can tell they should be. See: http://dev.w3.org/html5/webvtt/#webvtt-cue-text-dom-construction-rules.

Comment 4

[Blake Wu [:bwu][:blakewu]]

This should be related to layout.

Comment 5

[Benjamin Chen [:bechen]]

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

Comment 6

[Boris Zbarsky [:bzbarsky]]

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.

Comment 7

[Cameron McCormack (:heycam)]

(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.)

Comment 8

[Boris Zbarsky [:bzbarsky]]

Ah, good point.  If devtools can examine these nodes (can they?) then I agree we shouldn't stomp on their API.

Comment 9

[Cameron McCormack (:heycam)]

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.

Comment 10

[Alastor Wu [:alwu][PTO until 12/16]]

FYI, Chrome supports :past and :future, here is the test case, 
https://people-mozilla.org/~alwu/WebVTT/vttTest.html