865395 - (vtt-css-extensions) [meta][webvtt] Implement vtt css-extensions (::cue, ::cue-region, :past, :future)

Status: NEW

(Core :: Layout, enhancement, P3)

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




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

Comment 1

[Boris Zbarsky [:bzbarsky]]

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?

Comment 2

[Rick Eyre (:reyre)]

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.

Comment 3

[Ralph Giles (:rillian)]

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.

Comment 4

[Boris Zbarsky [:bzbarsky]]

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?

Comment 5

[Rick Eyre (:reyre)]

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.

Comment 6

[Caitlin Potter (:caitp)]

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.

Comment 7

[Rick Eyre (:reyre)]

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.

Comment 8

[Boris Zbarsky [:bzbarsky]]

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

Comment 9

[Rick Eyre (:reyre)]

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.

Comment 10

[Boris Zbarsky [:bzbarsky]]

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

Comment 11

[Rick Eyre (:reyre)]

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

Comment 12

[u564613]

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.

Comment 13

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

This should be related to layout.

Comment 14

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

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

Comment 15

[Anthony Jones (:ajones, :kentuckyfriedtakahe, :k17e)]

https://webcompat.com/issues/3057#issuecomment-243085371

Comment 16

[Astley Chen (inactive)]

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

Comment 17

[Benjamin Chen [:bechen]]

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

Comment 18

[Nataly Magluy]

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

Comment 19

[Benjamin Chen [:bechen]]

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

Comment 20

[Alastor Wu [:alwu]]

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

Comment 21

[Alastor Wu [:alwu]]

Some heads-up here:
We did support using ::cue in document (bug 1318542), which is pseudo element, but did NOT support using that directly from vtt files (bug1321490) and using cue selector (bug1321489).
We did NOT support ::cue-region and its selector (bug1338031).
We did NOT support pseudo class, such as :past, :future (bug865401).

Comment 22

[Thomas Wisniewski [:twisniewski]]

KKTV.me long ago fixed the known webcompat issue. As there is no other reported webcompat fallout left to address, let's unset the webcompat priority flag for now.