Wide Review Comment 2017: position and size reference is video or video viewport?

[nigelmegitt]

Copy/paste from https://lists.w3.org/Archives/Public/public-tt/2017Sep/0080.html - raising as an issue for tracking/disposition purposes.

In some places sizes and positions are defined relative to the video viewport; in others the video itself. This is likely to cause some confusion or mis-alignment when the two are not the same (e.g. a 16:9 aspect ratio video is displayed in a 14:9 viewport) and creates an authoring problem. For example the cue box size is relative to the video but the cue box line is relative to the video viewport (both defined within section 3.1).

[nigelmegitt]

Additional point on this - there are some places where the vw and vh CSS units are used for positioning and sizing, yet they do not seem to accommodate scenarios where video is not shown full-window. Note that vw and vh are always relative to the initial containing block.

I'm happy to be shown otherwise but I don't believe that CSS currently has a concept for setting a local viewport within which the vw and vh units are resolved. This means that the rule:

The viewport (and initial containing block) is video’s rendering area.

does not actually seem to be implementable - I see that there's an open Chromium bug on this at https://bugs.chromium.org/p/chromium/issues/detail?id=244618 raised by people who found this a lot earlier than me.

[silviapfeiffer]

About first comment: Well spotted - "a percentage of the video" means nothing - it should indeed be "video viewport".

About second comment: The way CSS is defined, vh and vw refer to the viewport, which is the "containing block" as per https://www.w3.org/TR/CSS21/visudet.html#containing-block-details . This also states that for media elements the "initial containing block" is the video viewport, so all WebVTT dimensions are calculated with respect to the block provided by the video. That is independent of whether the video is fullscreen or not - it's always relative to the actual rendered dimensions of the video. The sentence you quoted is merely repeating what the CSS spec says.

The bug that you are referring to simply says that Chromium's implementation of vh and vw for all shadow DOM elements of the video element (and that includes WebVTT rendering) is broken.

[dwsinger]

are vw and vh established by the containing context (e.g. HTML) if any, or are they reset by the video element? If the latter, then it won't be possible to be consistent in e.g. font sizing. The phrase "The viewport (and initial containing block) is video’s rendering area." essentially sets a context for this instantiation of CSS. Perhaps it needs to say "The CSS viewport (as defined in CSS 2.1 section XX)..."

[dwsinger]

Do we need to say that the root element from CSS's point of view is the video viewport, to be clear? Or the initial containing block?

[silviapfeiffer]

Resolution at TPAC:

This is fundamental to the specification of WebVTT:
"The viewport (and initial containing block) is video’s rendering area."
It needs to be in a better location and explain how vh and vw are interpreted in this context.

It may even be important to clarify this for CSS in general, because the video shadow DOM should apply only to the video element's rendering area, not the full Web page - should be discussed with CSS WG?

[dwsinger]

Note that this means that a naive javascript implementation is hard, because it's not easy to establish a new CSS sandbox/context?

[dwsinger]

(We need to loop back around with CSS)

[silviapfeiffer]

Did you get to talk to the CSS group about this?