Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[css2][css-images] Zero or infinite intrinsic ratio #4572

SimonSapin opened this issue Dec 7, 2019 · 4 comments

[css2][css-images] Zero or infinite intrinsic ratio #4572

SimonSapin opened this issue Dec 7, 2019 · 4 comments


Copy link

SimonSapin commented Dec 7, 2019

Consider this test case:

img { border: solid 1px }
p img { height: 10px }
div img { width: 10px }
<p><img src="data:image/svg+xml,<svg xmlns='' height='2' width='10'></svg>"></p>
<p><img src="data:image/svg+xml,<svg xmlns='' height='1' width='10'></svg>"></p>
<p><img src="data:image/svg+xml,<svg xmlns='' height='0' width='10'></svg>"></p>
<img src="data:image/svg+xml,<svg xmlns='' height='10' width='2'></svg>">
<img src="data:image/svg+xml,<svg xmlns='' height='10' width='1'></svg>">
<img src="data:image/svg+xml,<svg xmlns='' height='10' width='0'></svg>">

Its rendering is interoperable in Firefox 70 and Chromium 78:

Relevant specs:


The intrinsic aspect ratio must be calculated using the following algorithm. If the algorithm returns null, then there is no intrinsic aspect ratio.

If the width and height sizing properties on the ‘svg’ element are both absolute values:

return width / height

So I would expect the respective intrinsic ratios for those six img elements to be 5, 10, infinity, 0.2, 0.1, and zero.

Each img has has one of or width or height set to a 10px, and the other has its initial value auto. Given this and the presence of an intrinsic ratio, both CSS 2 and css-images specify that the auto dimension should be resolved based on the non-auto one and intrinsic ratio. So I would expect the respective missing sizes to be 50px, 100px, infinity, 50px, 100px, and infinity. With infinities possibly clamped to some large finite value.

This is what happens, except for images 3 and 6. Instead, both browsers seem to behave is if they did not have an intrinsic ratio, taking the missing dimension from their intrinsic size:

In css-images:

If the specified size is only a width or height (but not both) then the concrete object size is given that specified width or height. The other dimension is calculated as follows:

  1. If the object has an intrinsic aspect ratio, the missing dimension of the concrete object size is calculated using the intrinsic aspect ratio and the present dimension.

  2. Otherwise, if the missing dimension is present in the object’s intrinsic dimensions, the missing dimension is taken from the object’s intrinsic dimensions.

CSS 2 is organized differently but is effectively equivalent to the above as far as I can tell.

Should css-images specify an intrinsic ratio of zero or infinity must be treated as missing?

Copy link
Contributor Author

CC editors @tabatkins @fantasai @LeaVerou. I think there’s (at least some) unspecified interop here?

Copy link

The CSS Working Group just discussed Zero or infinite intrinsic ratio, and agreed to the following:

  • RESOLVED: treat aspect ratio of 0 or infinity as auto, propagate to the aspect-ratio property behavior as well
The full IRC log of that discussion <Rossen_> Topic: Zero or infinite intrinsic ratio
<TabAtkins> github:
<Rossen_> github:
<fremy> TabAtkins: someone brought up an interesting test case showing the effect of an svg with infinite width or height ratio
<fremy> TabAtkins: in both cases, browsers treat it as having no ratio at all
<fremy> TabAtkins: (see examples in the issue)
<fremy> TabAtkins: this is not specified right now
<fremy> TabAtkins: if you just follow the spec right now, you should get an infinite ratio, not what we have right now
<fremy> TabAtkins: but we can add an exception in the images spec to cover this so implementation won't have to change
<fremy> florian: but that is different from the aspect-ratio behavior?
<fremy> TabAtkins: yes, I think this is just for compat, there is no good reason for this
<fremy> TabAtkins: but since it's not very important, matching legacy makes sense to me
<Rossen_> q
<fremy> fantasai: I think it's weird we do two different things
<fremy> emilio: or we could make the aspect-ratio do the same thing
<fremy> TabAtkins: we are probably fine to go either way in behavior
<fremy> TabAtkins: if we want to align, I am happy to do that do
<fremy> florian: can we do the reverse? the property does what svg does now
<fremy> TabAtkins: would break consistency, but both will
<fremy> florian: let's do that, sounds like an error case
<fremy> fantasai: yeah, lets be consistent
<fremy> fantasai: either the svg or the prop, and let's pick it
<fremy> Rossen_: I think the second one is easier on implementation
<fremy> TabAtkins: it's not yet implemented
<fremy> Rossen_: for svg
<fremy> Rossen_: it's more difficult to fix svg
<fremy> TabAtkins: that violates our open-bound policy
<fremy> TabAtkins: I don't like that much
<fremy> TabAtkins: but ok, I'm willing to bend on this because it's not important
<fremy> emilio: but infinity can't map to infinity anyway
<fremy> emilio: there is a limit
<fremy> TabAtkins: clamping doesn't break continuity
<fremy> TabAtkins: so there is not reason not to clamp
<fremy> TabAtkins: but I could go either way
<fremy> Rossen_: given there is no strong reason in either direction, let's try to resolve to do the same as current svg?
<fremy> florian: the svg spec says one thing
<fremy> florian: the svg should fix their spec too
<fremy> florian: otherwise we make a weird exception for aspect-ration then down the line someone can fix the svg code
<fremy> chris: well, that's a bug in the spec
<fremy> chris: svg2 was not supposed to add new features
<fremy> chris: so we should fix the spec not to allow this
<fremy> Rossen_: I am fine reaching out to svg if we resolve this
<fremy> Rossen_: any objection?
<chris> s/new features/new features and to document existing behavior/
<fremy> TabAtkins: proposed resolution is to treat aspect ratio of 0 / infinity as auto
<fremy> TabAtkins: this willl propagate to the prop behavior as well
<fremy> RESOLVED: treat aspect ratio of 0 or infinity as auto, propagate to the aspect-ratio property behavior as well

Copy link
Contributor Author

Is auto for the purpose of this discussion the same as "does not have an intrinsic aspect ratio"?

Copy link


Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet

No branches or pull requests

6 participants