-
Notifications
You must be signed in to change notification settings - Fork 673
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
Labels
Milestone
Comments
CC editors @tabatkins @fantasai @LeaVerou. I think there’s (at least some) unspecified interop here? |
The CSS Working Group just discussed
The full IRC log of that discussion<Rossen_> Topic: Zero or infinite intrinsic ratio<TabAtkins> github: https://github.com//issues/4572 <Rossen_> github: https://github.com//issues/4572 <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 |
Is |
Yes. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
Consider this test case:
Its rendering is interoperable in Firefox 70 and Chromium 78:
Relevant specs:
In SVG:
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 orwidth
orheight
set to a10px
, and the other has its initial valueauto
. Given this and the presence of an intrinsic ratio, both CSS 2 and css-images specify that theauto
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:
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?
The text was updated successfully, but these errors were encountered: