User Agent: Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.64 Safari/537.31 Expected results: The :cue pseudo-element needs to be implemented so that the anonymous content created by the WEBVTT parser can be accessed through it. See: http://dev.w3.org/html5/webvtt/#the-cue-pseudo-element

This will take a bit of style system surgery... Nothing like that around yet. Does it need to respond to dynamic changes, or does the anonymous content not mutate?

The anonymous content can change via adding or removing cues to tracks through script. See http://dev.w3.org/html5/webvtt/#webvtt-api. The user would create a new cue and then call addCue() on the TextTrack.

However, content has to go through that interface, so the anonymous content can only mutate under control of the containing media element. So we can arrange for a particular object to marshall updates.

So the question is whether in our implementation that would rebuild all anonymous content from scratch or just mutate its DOM. The former is much simpler to handle, I suspect, but may not be possible if people are expected to add/remove cues a lot... Can script detect what styles are being applied somehow? Or would we be able to just lazily mark the anon content as dirty when cues are added/removed and then rebuild it async when we feel like it?

I don't think script is able to detect what styles are being applied because all the styles are set through the 'text' member of the TextTrackCue which is then parsed when it is ready to display. I'm not to sure on being able to detect what has changed. There are some events that are fired when a cue is removed or added to a text track, but they don't say which cue has changed. Not very useful.. Haven't read anything on being able to detect a cue whose cuetext has only changed though.

This is probably a bug in the spec, re only notified of updates, but not of which cue is updated or not. Perhaps we should file a bug on the spec regarding this. At least then we should get an explanation as to why.

Just clarified on #whatwg. Whenever any one of a TextTrackCue's members changes we need to update the display state of the TextTrackCue. If we want to set a flag that will allow us to know when it has changed and then update it lazily that is an implementation detail for us.

OK. That's good; that gives us a lot more leeway in terms of how we can implement this stuff.

If it's possible could we get a high-level overview of what needs to change to implement this bz? We spoke to dbaron in Taiwan about it, but more information is always better.

Well, for starters you would need to add limited support for pseudo-elements with arguments. Right now we have a special-case for the tree cases; that _might_ be the way to go here. The rest of this would presumably look much like the patch that added the ::placeholder pseudo-element in terms of the property restructions and whatnot. Except that the fact that the set of property restrictions depends on the selector inside the ::cue is pretty weird. It raises the question of exactly how this thing is supposed to work. Right now, properties apply (or not) to the pseudo-element. Then you can select this pseudo-element with selectors. But this spec says that what properties apply depends on the _selector_, which raises the question of what the heck that actually means. Most likely that whoever wrote the spec doesn't understand the difference between a pseudo-element and a pseudo-element selector....

I don't have plans to work on this until after bug 865407 which might take a while.

CSS styling for WebVTT is already implemented in Chrome, Safari, Opera & Microsoft Edge browsers, so it would be wise for Firefox to implement this sooner rather than later.

This should be related to layout.

Reset Assignee to default since it seems Rick has not worked on this for a while.

Benjamin, are you going to take this bug as meta bug for implementation ?

Yes, for example: 1. support ::cue from document. 2. support ::cue from vtt file. 3. support ::cue(xxx)

Hi! Are there any plans to implement this? Is it possible to style captions on FF in any other way?

(In reply to Nataly Magluy from comment #18) > Hi! Are there any plans to implement this? Is it possible to style captions > on FF in any other way? Yes, we are going to support style captions. Since I treat this bug as a meta bug for tracking status, no more detail progress here. If you need more information about this, you can see other bugs in the dependent tree.

Change this bug as a meta bug for tracking all webVTT CSS extensions related bugs.