Open Bug 1321490 Opened 9 years ago Updated 2 years ago

[webvtt] support ::cue pseudoelement from vtt file.

Categories

(Core :: Audio/Video: Playback, enhancement, P3)

enhancement

Tracking

()

People

(Reporter: bechen, Unassigned)

References

(Blocks 1 open bug, )

Details

Attachments

(1 file)

The ::cue may appears in .vtt file, I guess we need to inject it into our style/layout system.
Assignee: nobody → bechen
Comment on attachment 8834294 [details] Bug 1321490 - part1: Parse the STYLE content in vtt file. Through the styleElement to get a styleSheet. https://reviewboard.mozilla.org/r/110282/#review111840 After discuss with :heycam, the patch doesn't work because the styleElement append to the <head> will effect all nodes in dom tree. And we want the styleElement/styleSheet only apply to one specific video element, not the whole document. So :heycam will help to add new api/function at nsDocument such as: 1. function creatStyleSheetFromString(), input is a nsAString from vtt file and output a styleSheet. 2. function addStyleSheetToSpecificNode(), input is a styleSheet and apply the styleSheet to a specific video element.
Email with :heycam :heycam If we decide that we should indeed support style sheets embedded in WebVTT files (if the other vendors who support WebVTT indicate that do or will support it, or if we really think it is a useful feature to implement first), then here are some notes on how to handle it. There are a two things we need to ensure: (a) That the embedded style sheet can only match ::cue pseudo-elements for that one <video> element. (b) That its rules are applied at the right level of the cascade, so that its rules will override any ::cue rules in the outer document. So I think we want two C++ APIs for this: 1. A function that can take a string (the style sheet text) and parse it as a style sheet, and return it as a mozilla::StyleSheet object. The returned style sheet would be stripped of any rules other than ::cue rules. (Did we find out whether @supports is allowed?) I'm not sure where that function should live, but it probably doesn't matter too much. (It is a bit similar to nsStyleSheetService::PreloadSheet.) 2. A function on nsIDocument that takes a StyleSheet* and an Element*, and which adds the style sheet to a new level of the cascade (between SheetType::ScopedDoc and SheetType::StyleAttr, I think). The semantics of this function would be that it applies the style sheet only to native anonymous content whose "real" element is the Element* that was passed in (the <video>). Or: maybe we can re-use the existing scoped style sheet support of nsStyleSet somehow, but that might be going away with stylo -- we haven't decided yet. In any case, we should decide first whether we really want to support this. If we do, then we we can decide the best approach to handle #2. Either way it is going to be some work to make this work in Servo for stylo, too, which we will need to do. Benjamin Chen <bechen@mozilla.com> :bechen I just found a complicate scenario: One MediaElement with multiple TrackElements and each TrackElement has its own style context in vtt file. In addition, the TrackElement can be turn on/off at runtime. So we might also need 1. a function that we can remove the sheet we have inject at the Element 2. apply the stylesheet to a group of cues/ or enable some stylesheet at runtime. The status of a TrackElement are Disabled, Hidden, Showing. And we only show the cues which mode is Showing. Then if we disable a TrackElement, we can remove a stylesheet. And if we hide a TrackElement, we can turn off the stylesheet... Or just enable the styleSheet which TrackElement is showing... Cameron McCormack 透過 messagingengine.com :heycam Yes. nsIDocument has a function to remove a style sheet, so we will have to make sure that it works for the style sheet that we add using the new function. Or we can disable and re-enable the sheets, as you say. But we need a function to remove the style sheet anyway, for when the <track>/<video> element is removed from the document.
Assignee: bechen → nobody
Blocks: 1499802
No longer blocks: 1499802
Depends on: 1321489
No longer depends on: 1321489
Severity: normal → S3
Type: defect → enhancement
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: