Chromium browsers do not currently support the `lineAlign` or
`positionAlign` properties on the VTTCue class, just like the region
property. So this pull request adds an if before reading those
properties so that the position and line values are handled correctly in
UITextDisplayer (without this change the subtitles are always at the
bottom edge of the player and right aligned subtitles are displayed
off-screen).
https://developer.mozilla.org/en-US/docs/Web/API/VTTCue/lineAlign#browser_compatibilityhttps://developer.mozilla.org/en-US/docs/Web/API/VTTCue/positionAlign#browser_compatibility
Before fix

After fix

Steps to reproduce:
- Get local demo running (`python build/all.py --debug`?)
- Visit custom content, add
https://d2zihajmogu5jn.cloudfront.net/elephantsdream/ed_hd.mp4 (with
whatever name)
- Add track below
- Start playing custom video, switch Captions to the new text track
**JS to add text track**
```js
await document.getElementById('video').ui.getControls().getPlayer().addTextTrackAsync('data:text/vtt;charset=utf-8,WEBVTT%0AKind%3A%20subtitles%0ALanguage%3A%20en%0A%0A00%3A00%3A00.000%20--%3E%2000%3A01%3A00.000%20align%3Astart%20position%3A0%25%20line%3A0%25%0ATop%2FLeft%0A%0A00%3A00%3A00.000%20--%3E%2000%3A01%3A00.000%20line%3A0%25%0ATop%2FCentre%0A%0A00%3A00%3A00.000%20--%3E%2000%3A01%3A00.000%20align%3Aend%20position%3A100%25%20line%3A0%25%0ATop%2FRight%0A%0A00%3A00%3A00.000%20--%3E%2000%3A01%3A00.000%20align%3Astart%20position%3A0%25%20line%3A48%25%0AMiddle%2FLeft%0A%0A00%3A00%3A00.000%20--%3E%2000%3A01%3A00.000%20line%3A48%25%0AMiddle%2FCentre%0A%0A00%3A00%3A00.000%20--%3E%2000%3A01%3A00.000%20align%3Aend%20position%3A100%25%20line%3A48%25%0AMiddle%2FRight%0A%0A00%3A00%3A00.000%20--%3E%2000%3A01%3A00.000%20align%3Astart%20position%3A0%25%0ABottom%2FLeft%0A%0A00%3A00%3A00.000%20--%3E%2000%3A01%3A00.000%0ABottom%2FCentre%0A%0A00%3A00%3A00.000%20--%3E%2000%3A01%3A00.000%20align%3Aend%20position%3A100%25%0ABottom%2FRight%0A%0A', 'en', 'subtitles', 'text/vtt')
```
Font settings were applied to ".shaka-video-container *", all
descendents of .shaka-video-container. This meant that the font setting
inheritance intended in our UI text displayer was broken, because those
descendents effectively had their own settings and didn't inherit them
from their parents in the subtitle DOM hierarchy. We fix this by
breaking down the CSS and applying those font settings directly to the
top level .shaka-video-container, to be inherited by any descendent
without their own setting.
> Quote from specs:
> Valid examples include:
> • "stpp.ttml.etd1" - TTML content suitable for presentation by an
EBU-TT-D renderer
> • "stpp.ttml.etd1|im1t" or "stpp.ttml.im1t|etd1" - TTML content
suitable for presentation by an EBU-TT-D or
IMSC1 renderer
Fixes#6831
This moves VTT sequence mode offset calculations into a method.
It also makes all X-TIMESTAMP-MAP usage dependent on HLS specifically,
rather than sequence mode, simplifying the conditions. Sequence mode is
typically only used with HLS, and X-TIMESTAMP-MAP is explicitly only for
HLS. So excluding X-TIMESTAMP-MAP for DASH makes sense, instead of
conflating HLS and sequence mode.
This required updating some tests to explicitly set both the manifest
type and sequence mode flag.
This does *not* change the offset calculations themselves. Changes will
be made in follow-up PRs.
Issue #6320
## Background:
The native DOM Parser can perform poorly on some older devices, this
approach is faster on newer devices but is considerably better on older
devices.
This PR replaces the usage of the DOM Parser for DASH, MSS, VTT and
TTML.
The draw back of this approach that it does not include any validation
at the cost of better performance.