Implement the ::cue pseudo-element

NEW
Unassigned

Status

()

Core
Layout
P3
normal
4 years ago
a month ago

People

(Reporter: reyre, Unassigned)

Tracking

(Depends on: 3 bugs, Blocks: 2 bugs, {dev-doc-needed})

Trunk
dev-doc-needed
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

4 years ago
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
(Reporter)

Updated

4 years ago
Blocks: 629350
(Reporter)

Updated

4 years ago
OS: Windows 8 → All
Hardware: x86_64 → All

Updated

4 years ago
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?
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Reporter)

Comment 2

4 years ago
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?
Summary: Implement the :cue pseudo-element → Implement the ::cue pseudo-element
(Reporter)

Comment 5

4 years ago
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.
(Reporter)

Comment 7

4 years ago
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.
(Reporter)

Updated

4 years ago
Assignee: nobody → rick.eyre
(Reporter)

Updated

4 years ago
Status: NEW → ASSIGNED
(Reporter)

Comment 9

4 years ago
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.
Flags: needinfo?(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....
Flags: needinfo?(bzbarsky)
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → WONTFIX
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
(Reporter)

Comment 11

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

Updated

4 years ago
Status: REOPENED → NEW
Component: Audio/Video → Audio/Video: Playback

Updated

2 years ago
Blocks: 1131952
Keywords: dev-doc-needed

Comment 12

2 years ago
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.
Component: Audio/Video: Playback → Layout
Reset Assignee to default since it seems Rick has not worked on this for a while.
Assignee: rick.eyre → nobody
See Also: → bug 1284803
See Also: → bug 1288648
https://webcompat.com/issues/3057#issuecomment-243085371

Updated

9 months ago
Depends on: 1318542
Benjamin, are you going to take this bug as meta bug for implementation ?
Flags: needinfo?(bechen)
Priority: -- → P3
Yes, for example:
1. support ::cue from document.
2. support ::cue from vtt file.
3. support ::cue(xxx)
Flags: needinfo?(bechen)

Updated

9 months ago
Depends on: 1321488

Updated

9 months ago
Depends on: 1321489

Updated

9 months ago
Depends on: 1321490

Updated

8 months ago

Updated

7 months ago
Depends on: 1330843

Updated

7 months ago
Blocks: 1332564

Comment 18

6 months ago
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.
You need to log in before you can comment on or make changes to this bug.