This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
I don't quite see the point of using 'vh' and 'vw' and redefining the initial containing block to the video's rendering area when we could just use percentage values as easily as we are positioning all of these boxes absolutely within the video's rendering box. The percentage will set it to % to the left, width, right, etc, of the containing element which is always the video rendering area. If this is specifically for the case of regions, as we still want to specify position, etc, as a percentage of the video I think it would make more sense to have position, etc, specify values relative to the region as this is what the author is positioning their cues in now.
I don't understand - vh and vw are defined as percentage values: http://dev.w3.org/csswg/css-values/#viewport-relative-lengths What is your problem?
They are translated to percentage values of the initial containing block. So in order for them to work as they do in the current spec the 'initial containing block' needs to be redefined as the video view port, which has been done. However, this would take some changing to the way 'vh' and 'vw' work in the implementation because we need to redefine what the initial containing block is for this special case. It would be easier to just use straight '%' values as the CSS units instead of 'vh' and 'vw' as they have the same meaning as 'vh' and 'vw' as defined by the WebVTT spec.
In both implementations I have worked on (Presto and Blink) it's the case that the vh/vw isn't actually used internally, because as Rick says it's extra work to make them relative to the video in this special case. Instead, in Presto we just did the calculation using the video size internally, and in Blink percentages are used instead. So, I'm quite sympathetic to having the spec use percentages instead. However, I think the vh/vw units have a purpose for styling the text using CSS. Without them, is there actually any unit one could use to make the text grow and shrink with the video? This seems important to have, and the work required to support that is the same as is required to allow the implementation to use them internally as well... Thoughts?
Aren't video height and vh required to stay in sync? So you want to specify everything in percentage values relative to the "initial containing block", except for the font size and line height?
(In reply to Silvia Pfeiffer from comment #4) > Aren't video height and vh required to stay in sync? > > So you want to specify everything in percentage values relative to the > "initial containing block", except for the font size and line height? Both vh and % would stay in sync with reality, the problem is that actually making vh is a bit of work so we should make sure we actually need it. I can't think of another way to specify relative font sizes, so we probably do need it...
(In reply to Philip Jägenstedt from comment #3) > In both implementations I have worked on (Presto and Blink) it's the case > that the vh/vw isn't actually used internally, because as Rick says it's > extra work to make them relative to the video in this special case. Instead, > in Presto we just did the calculation using the video size internally, and > in Blink percentages are used instead. > > So, I'm quite sympathetic to having the spec use percentages instead. > However, I think the vh/vw units have a purpose for styling the text using > CSS. Without them, is there actually any unit one could use to make the text > grow and shrink with the video? This seems important to have, and the work > required to support that is the same as is required to allow the > implementation to use them internally as well... > > Thoughts? Yes, I see your point. Internally Firefox uses percentages that are relative to the video view port. Which technically is 'vw and vh with the initial containing block redefined to the video viewport'. But we don't go through the trouble of actually redefining the viewport and using vh and vw units. However, I can see how from the authors point of view it might make more sense to use vh or vw when setting WebVTT styles since their concern is only with the styles of the captions at that point.
(In reply to Rick Eyre from comment #6) > (In reply to Philip Jägenstedt from comment #3) > > In both implementations I have worked on (Presto and Blink) it's the case > > that the vh/vw isn't actually used internally, because as Rick says it's > > extra work to make them relative to the video in this special case. Instead, > > in Presto we just did the calculation using the video size internally, and > > in Blink percentages are used instead. > > > > So, I'm quite sympathetic to having the spec use percentages instead. > > However, I think the vh/vw units have a purpose for styling the text using > > CSS. Without them, is there actually any unit one could use to make the text > > grow and shrink with the video? This seems important to have, and the work > > required to support that is the same as is required to allow the > > implementation to use them internally as well... > > > > Thoughts? > > Yes, I see your point. Internally Firefox uses percentages that are relative > to the video view port. Which technically is 'vw and vh with the initial > containing block redefined to the video viewport'. But we don't go through > the trouble of actually redefining the viewport and using vh and vw units. > > However, I can see how from the authors point of view it might make more > sense to use vh or vw when setting WebVTT styles since their concern is only > with the styles of the captions at that point. How have you worked around the fact that the default font is '5vh sans-serif'? Regardless, I think that viewport-relative units in author-provided CSS is too important to give up on, so we'll just have to try to implement this instead. If that doesn't happen within a few years or if multiple vendors say it's just too hard (doubtful) then we'll have to revisit this issue.
In other words, WONTFIX for now.
(In reply to Philip Jägenstedt from comment #7) > How have you worked around the fact that the default font is '5vh > sans-serif'? We're still half-way through implementing that.