You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Desired behavior
Rather than have the cue styles applied as inline styles, they should be applied as a list of styles within a stylesheet. This would allow for clients to easily override cue styles where necessary.
Concerns
It’s paramount that vtt.js continues to provide a way for consumers to get cue styles out of the box as, without them, the cues would not be accessible. Rather than changing the default behavior, we should look to provide new behavior behind an option.
We should make sure that this doesn’t prevent the implementation of the two currently in-flight PRs #35 and #27.
Proposed solution
Modify the processCues method’s signature such that it accepts an options object. The object will accept the following options:
window
cues
overlay
inlineStyles: true // default value. When true, styles will be applied to cues inline.
[inlineStyles=true] - When true, styles will be applied to cues inline. [onapplystyles=null] - A callback function that is called when styles are applied to the cue. The callback is called with two arguments:
styleObj - a hash containing a mapping of style names to their respective values.
displayState - The element to which the styles should be applied
By default, cue styles will be applied directly to cue elements.
Pass the options object to CueStyleBox, and set the options hash on the CueStyleBox instance (e.g this._processorOptions = options);
The consumer is responsible for handling, and implementing, the styles that are sent in the onapplystyle callback.
Desired behavior
Rather than have the cue styles applied as inline styles, they should be applied as a list of styles within a stylesheet. This would allow for clients to easily override cue styles where necessary.
Concerns
It’s paramount that vtt.js continues to provide a way for consumers to get cue styles out of the box as, without them, the cues would not be accessible. Rather than changing the default behavior, we should look to provide new behavior behind an option.
We should make sure that this doesn’t prevent the implementation of the two currently in-flight PRs #35 and #27.
Proposed solution
The text was updated successfully, but these errors were encountered: