Html-rendered subtitles are displayed over html popup window

[KozhinM]

Repro steps:

1. Open dash-if-reference-player
2. Start playing mpd with CC, e.g.:
   http://rdmedia.bbc.co.uk/dash/ondemand/elephants_dream/1/client_manifest-all.mpd
3. Click on "Stream" drop down menu.
4. Observe: drop down list is displayed over the player.
5. Wait till subtitles are show. Observe: they are displayed over the drop down list:

[TobbeMobiTV]

@KozhinM The subtitles div has the highest z-order possible in order to be visible on top of the fullscreen video. Unfortunately, we don't know when we are in full-screen mode. Some type of external call may be needed to hide the subtitles in a case like this when something else should be on top.

[nigelmegitt]

There's a UX issue here for people using subtitles because they can not hear: whereas hearing viewers know what the audio is when they are interacting with the player or its controls, non-hearing viewers probably still want to be know when there is dialogue while they are interacting with the player. Since the subtitles come and go, arguably the current behaviour is actually correct. It could maybe be made a user setting?

[KozhinM]

@TobbeMobiTV, actually we can detect if we are in a full screen mode or not - we can use document.fullscreenElement property (in Edge) for it (or msFullscreenElement for IE11 or webkitFullscreenElement for Chrome/Safari). It is "null" then we are not in full screen and "video" when we are in full screen.
@nigelmegitt, I see your point, but allowing subtitles to be displayed on top may also lead to a UX issue. For example, what if there is a yes/no dialogue which is shown in the middle of the player window. It may happen that the subtitles hide the header or even buttons of such window. I think that CC should have the same visibility priority as the player itself. Besides, in most cases such popup dialogues are opened by user request, so it is expected that if they open, they have a higher priority.

[nigelmegitt]

@KozhinM Yes, I agree there must be some 'highest level' that anything rendered in the player can reach, that can be obscured by something else that's more important. I'm not sure what that highest level should be though.

One possibly helpful analogy to use when thinking about this problem if you can hear well is: "how would you feel if the player started making sounds that obscured the programme dialogue while you were listening to it?"

[KozhinM]

@TobbeMobiTV, I suppose we can also use CSS pseudo-class :fullscreen:
https://developer.mozilla.org/en-US/docs/Web/CSS/%3Afullscreen

[KozhinM]

@nigelmegitt, well, good point. I think a configurable option would be a good compromise in this case indeed.

[KozhinM]

We may also set opacity=0.5 for the cue background just like native captions have it. This would make the popup dialogues a bit more readable.

[nigelmegitt]

@KozhinM The opacity is specified in the TTML data. Do you mean to change the opacity only when a UX element is inserted between the subtitles/captions and the video, or all the time? If you do it all the time you should be aware that you're diverging from the specs.

For what it's worth, I do think there may be a reasonable general argument for modifying the display of TTML subtitles deliberately when UX elements occupy the same area as the subtitles want to. It's just that there's no specification for exactly how it should/could be done. If you want to keep dash.js as a reference player then you probably should just stick to the specifications though.

[TobbeMobiTV]

@KozhinM Using the fullscreenElement attribute to trigger a change in the z-index works well (I've only tested on Chrome this far).

We got errors when trying to set CSS pseudo-class attributes programmatically on both IE11 and Firefox, so I'd rather not go that path.

The native cues, at least on Chrome, are slightly transparent as you say, but they don't change as the menu appears on top of them. As @nigelmegitt said, the content creator can choose to set the background opacity. We could add it to some of our test content.

In any case, I'll test a little more and make a PR for a fix of this issue.

[KozhinM]

@TobbeMobiTV, @nigelmegitt, I implemented API to control captions z-index value:
#781
Regarding opacity - since this is something ttml creators responsible for, let it be as it is now.

[TobbeMobiTV]

@KozhinM #781 looks fine.

[nigelmegitt]

Thanks @KozhinM looks fine for now.

A future possible development to consider would be to dynamically move subtitles to avoid overlap when there's another UI element taking up space over the video, especially if that can be done simply by adding/removing a CSS class.