New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 311346 link

Starred by 2 users

Issue metadata

Status: Untriaged
Owner: ----
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 3
Type: Bug

Sign in to add a comment

<video> instrinsic width/height is not per spec

Reported by, Oct 24 2013

Issue description

The intrinsic width of a video element's playback area is the intrinsic width of the poster frame, if that is available and the element currently represents its poster frame; otherwise, it is the intrinsic width of the video resource, if that is available; otherwise the intrinsic width is missing.

The intrinsic height of a video element's playback area is the intrinsic height of the poster frame, if that is available and the element currently represents its poster frame; otherwise it is the intrinsic height of the video resource, if that is available; otherwise the intrinsic height is missing.

In Blink the order of poster frame and video frame is reversed, and the default intrinsic width is 300x150 instead of missing. The difference is that the video will have an intrinsic ratio 2:1, so a video with no src and only a width="100" will be 100x50, whereas it should be 100x150 per spec, since the "default object size" is 300x150.

Comment 1 by, Oct 24 2013

Related to  issue 310122 .

Comment 2 by, Mar 21 2016

Components: -Blink>Video Blink>Media>Video
Renaming Blink>Video to Blink>Media>Video for better characterization
Labels: Needs-Feedback
Philip, this is quite an old issue. I'm wondering how much still applies. Would you be able to tell off hand? Do you also have a test case handy? :)
Labels: -Needs-Feedback
Status: Available (was: Untriaged)
The spec also says (after the first two paragraphs quotes by Philip):

"The default object size is a width of 300 CSS pixels and a height of 150 CSS pixels."

If I add an empty <video> element to the page, its videoWidth/Height attributes are reported to be 0 (missing) as per spec, while the size of the object is 300x150, also per spec. So I think the bigger chunk of the last paragraph in #0 doesn't match the current implementation.

Adding a poster image though doesn't work as expected - the reported videoWidth and videoHeight are still 0. Per spec, the video element represents its poster frame when it has no data so the videoWidth and videoHeight should be matching the size of the poster image. width/height are also 0s in both cases (shouldn't width/height report the actual size of the element on the page no matter what?).

I wonder if there're sites relying on the behavior though...

Comment 5 by, Jul 22 2016

The poster size shouldn't affect the videoWidth or videoWidth attributes, it only affects the layout size of the video element.

The final paragraph of the original issue description is still true I think, so one test case would be this:

<!DOCTYPE html>
div { width: 150px; height: 150px; background: red }
video { width: 150px; background: green }
<p>there should be no red

(This doesn't test the order of poster size vs video frame size, just that the element doesn't have an intrinsic ratio.)

Comment 6 by, Jul 23 2016

Test hosted at

I tested recent versions of Chrome, Safari, Firefox and Edge and they all fail this test, i.e. they give the video element an intrinsic aspect ratio.

Comment 7 by, Jul 23 2016

Labels: -Pri-2 Pri-3
One way of "fixing" this is to simply change the HTML spec to give video elements an intrinsic width/height of 300x150 instead of a default object size, to match implementations.

I think the risk of aligning with the spec is low, but the value is also low. Lowering the priority of this issue, and if no implementation changes in another year or so I think the spec should just change instead.
Labels: Needs-BlinkMediaTriage

Comment 9 by, Mar 28 2017


Comment 10 by, Mar 28 2017

Labels: -Needs-BlinkMediaTriage
Using the test page is #6, I could find a full compatibility between Chrome, Safari, Edge and Firefox. I think we should change the spec indeed.
Project Member

Comment 12 by, Nov 9

Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit - Your friendly Sheriffbot

Sign in to add a comment