This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html Section: http://www.whatwg.org/specs/web-apps/current-work/#video Comment: Defer <video> rendering (letterboxing) to CSS Posted from: 83.218.67.122
The spec currently says "Video content should be rendered inside the element's playback area such that the video content is shown centered in the playback area at the largest possible size that fits completely within it, with the video content's aspect ratio being preserved. Thus, if the aspect ratio of the playback area does not match the aspect ratio of the video, the video will be shown letterboxed or pillarboxed. Areas of the element's playback area that do not contain the video represent nothing." Opera has implemented support for CSS3 object-fit [1] and object-position [2] and I would like the spec to state the default rendering in terms of object-fit and object-position, as such: video { image-fit: contain; image-position: 50% 50% } We also support it for img, perhaps that should also be updated accordingly: img { image-fit: fill } Note that Opera's implementation is still prefixed: -o-object-fit and -o-object-position. [1] http://dev.w3.org/csswg/css3-images/#object-fit [2] http://dev.w3.org/csswg/css3-images/#object-position
I support this. The CSSWG has good agreement on the object-fit and object-position properties, and using them in the default stylesheet will help ensure that replaced elements are properly tweakable here.
Oops, image-fit and image-position are old names, I of course meant this: video { object-fit: contain; object-position: 50% 50% } We also support it for img, perhaps that should also be updated accordingly: img { object-fit: fill }
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Rejected Change Description: no spec change Rationale: This seems out of scope, no?
Shouldn't it be in the user agent style sheet, http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html#the-css-user-agent-style-sheet-and-presentational-hints ? If you think it belongs in some other spec, please remove the quoted paragraph on rendering requiring letterboxing, as that would otherwise contradict what "some other spec" says.
Agreed that it's out-of-scope - for HTML. ^_^ Philip's suggestion is correct - the rendering should be completely determined by CSS, as CSS has the necessary power to represent the desired rendering now. An informative line about the default rendering causing letterboxing behavior would still be acceptable, and probably useful.
So forgive my newbness here, but which spec defines the default background/foreground color, default margin/padding and so on for various HTML elements? It looks to me like at least some of it is in the section I linked to. Are there any other HTML elements which are explicitly mentioned in some other (CSS) spec and given default style? That's what would be required here, as img and video have different default styles, another talk about "images" or some such generic concept and get it right. I just want to have this defined in some spec so that other browsers won't have to reverse engineer (or worse, ignore) Opera when (if) implementing this, so please advise...
(In reply to comment #7) > another talk about "images" or some > such generic concept and get it right. Uh, let's try again. Any talk about "images" or some such generic concept would fail to get it right.
(In reply to comment #7) > So forgive my newbness here, but which spec defines the default > background/foreground color, default margin/padding and so on for various HTML > elements? It looks to me like at least some of it is in the section I linked > to. A combination of CSS (initial values for properties) and HTML (UA stylesheet). > Are there any other HTML elements which are explicitly mentioned in some other > (CSS) spec and given default style? That's what would be required here, as img > and video have different default styles, another talk about "images" or some > such generic concept and get it right. > > I just want to have this defined in some spec so that other browsers won't have > to reverse engineer (or worse, ignore) Opera when (if) implementing this, so > please advise... This should be defined in HTML, in the UA stylesheet. It's perfectly fine to have styles for <video> and <img> be different there.
(In reply to comment #9) > (In reply to comment #7) > > Are there any other HTML elements which are explicitly mentioned in some other > > (CSS) spec and given default style? That's what would be required here, as img > > and video have different default styles, another talk about "images" or some > > such generic concept and get it right. > > > > I just want to have this defined in some spec so that other browsers won't have > > to reverse engineer (or worse, ignore) Opera when (if) implementing this, so > > please advise... > > This should be defined in HTML, in the UA stylesheet. It's perfectly fine to > have styles for <video> and <img> be different there. Precisely, this was my thinking too. So it's not out of scope for HTML, then?
(In reply to comment #10) > (In reply to comment #9) > > This should be defined in HTML, in the UA stylesheet. It's perfectly fine to > > have styles for <video> and <img> be different there. > > Precisely, this was my thinking too. So it's not out of scope for HTML, then? Ah, talking past each other. I meant that it was out-of-scope for HTML to define the rendering itself, since CSS can now handle it. It's perfectly appropriate (and necessary) for HTML to define *what* CSS is used to handle it.
(In reply to comment #11) > (In reply to comment #10) > > (In reply to comment #9) > > > This should be defined in HTML, in the UA stylesheet. It's perfectly fine to > > > have styles for <video> and <img> be different there. > > > > Precisely, this was my thinking too. So it's not out of scope for HTML, then? > > Ah, talking past each other. I meant that it was out-of-scope for HTML to > define the rendering itself, since CSS can now handle it. It's perfectly > appropriate (and necessary) for HTML to define *what* CSS is used to handle it. Yep, this is what I'm suggesting: that we put something like this in the user agent style sheet: video { object-fit: contain; object-position: 50% 50% } img { object-fit: fill } (And like any default style it can be hardcoded, so it doesn't necessarily require browsers to support object-fit and object-position via CSS, although that would be nice.)
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Partially Accepted Change Description: see diff given below Rationale: I didn't give the rules that matched the initial values of those properties, since this is the UA style sheet. But other than that, done as suggested.
Checked in as WHATWG revision r5878. Check-in comment: Define that <video>'s default letterboxing is the result of CSS 'object-fit' http://html5.org/tools/web-apps-tracker?from=5877&to=5878
mass-move component to LC1