[css-sizing] Intrinsic Size of Images with Intrinsic Aspect Ratio and No Size

[fantasai]

So, we just checked in some rules for handling replaced elements with no intrinsic size:
https://drafts.csswg.org/css-sizing-3/#intrinsic-sizes
These are modeled after the rules in CSS2.1 chapter 10. We'd appreciate review, for sure.

Additionally, there is one case which is totally undefined in CSS2.1: intrinsic aspect ratio, no size, and the containing block depends on the size of the image. (Example: an SVG with a viewbox, no width/height attributes, inside an auto-sized float) This is a very unusual case, and our suggestion for handling it is to do what we do for orthogonal flows: use the stretch fit into the nearest scroll container.

Agenda+ for WG review of the new text and for determining what to do in the latter case.

[FremyCompany]

There is an existing issue open on that undefined case, with some interesting details. I'll try to find it back.

[FremyCompany]

#951 (comment)

[css-meeting-bot]

The CSS Working Group just discussed Intrinsic Size of Images with Intrinsic Aspect Ratio and No Size.

The full IRC log of that discussion

<dael> Topic: Intrinsic Size of Images with Intrinsic Aspect Ratio and No Size
<dael> github: https://github.com//issues/1609
<dael> fantasai: Wewon't reoslve here, but I wanted attention. I checked in some rules for this that are in the sizing spec and we'd appriciate review. There's another case in issue 951. There's no hints in 2.1 for this case and there's discussion there on how to handle it.
<AmeliaBR> q+
<dael> fantasai: So there's two things with these. We'd like review of the new text and we should resolve 951, but that's on the F2F agenda.
<Rossen_> ack AmeliaBR
<dael> AmeliaBR: I haven't looked into the various issues with as much detail as I'd like, but it looks like the specific issue of what to do when width is undefined...that's....basically there are a lot of thigns with SVG not defined in any spec but we're getting a defactor standard from browsers impl so you'd want somme tests to see what's already done.
<dael> AmeliaBR: I or someone else could do that before the meeting in a couple weeks. Sorry I didn't prepare before.
<AmeliaBR> s/defactor/de facto/
<dael> Rossen_: Good point. In terms of SVG and ways we compute intrinisic size and all the varitions...about a year ago we were revving our version of SVG sizing and at that time we did document what everyone is doing. I believe we have introp in most of the cases. The result of the work I believe was spec or tried to spec in the integration spec
<dael> Rossen_: If it didn't make it it should be there. Regardless it's a valid point and we should solidify and explain how that works. Definitely a big +1 from me
<AmeliaBR> https://www.w3.org/TR/SVG2/coords.html#SizingSVGInCSS
<dael> AmeliaBR: The text is SVG 2^
<dael> AmeliaBR: That's written in very SVG specific. For CSS you'd want to generalize, but it's written with CSS termonology. It can prob be resused. It doesn't cover min-width and max-width which becomes and issue w ith flexbox and grid layouts.
<dael> fantasai: This is defining what intrinisic dims the SVG has. THe SVG can return any combo of these as far as I'm aware.
<dael> fantasai: I thinkt he one combo they don't have is widht and height but no aspect ratio because you infer that.
<dael> Rossen_: Width and height with both % aren't.
<dael> fantasai: SVG says we don't have an aspect ratio in %
<dael> Rossen_: Width and height are computable.
<dael> fantasai: Spec says if width or height are auto or % CSS is told there is no width or height. CSS algo takes that to calc a box. CSS then tells the SVG here's your size. Then SVg uses information to draw inside the rectangle. This spec is about howto size that rectangle.
<dael> fantasai: When you're auto sized if the SVG has a width and height that's easy. If it has one or the other...it's missing some info...we need answers. IF it has aspect ratio ut not width or height browsers tend to use size of contaiing block to calc width and use aspect ratiof or height
<dael> fantasai: That gives you a fulls sized SVG image taking up width of containing block.
<dael> fantasai: So that's great and I think standardizing on that wehre we can is great. THere's one case with cyclic dependency. You can't use containing block size if that size depends on you.
<dael> fantasai: We need an answer for that size. I think there sin't consistancy in this respect. I think using 300px for the width is possible but not ideal. 951 is to find a better solution. Current proposal is same as what we do for orthgonal flows. We havea formula to find a size
<dael> fantasai: The rest of the cases are a little constrained. If you don't have any intrinisic size or aspect ratio, that's the iframe case and we use 330 x 150.
<dael> fantasai: We took t he 2.1 rules and tried to write them into Sizing. That one underfined case is on the F2F agenda.
<dael> Rossen_: That's 951?
<dael> fantasai: 951 is the open. Other we believe is consistant with 2.1, but it all requires a bunch of testing and i haven't done that.
<dael> fantasai: We're looking for review of CSS 3 Sizing to make sure it's correct and thoughts on 951.
<dael> Rossen_: I'm going to go back to your opening statement that this is more of an awareness call. I would side on taking this to the F2F and solving on a white boar.
<dael> Rossen_: Resolving now won't get us too far.
<dael> fantasai: If AmeliaBR would review that section we'd appriciate.
<dael> AmeliaBR: I'll try.
<dael> Rossen_: Will you be at F2F?
<dael> AmeliaBR: No.
<dael> [sadness]
<dael> Rossen_: Let us know if you can call in and we'll try and accomodate.

[AmeliaBR]

OK, we'll leave the discussion of the specific issue (what to do with an element that has an aspect ratio but no size, when it's container is sized based on contents) to #951.

Going over the rest of the new text:

Overall scope and organization

This section speaks specifically of min-content-size and max-content-size sizing. However, the discussion of max-content-size for elements with intrinsic aspect ratio:

• refers obliquely to a behavior that isn't explicitly defined anywhere, without a link: "If this size would depend on the size of the containing block (as it does for images with an intrinsic aspect ratio but no intrinsic size)..."
• then adds qualifications which are probably useful for the general auto-sizing case, not just for max-content-size.

CSS 2.1 has a "suggestion" (in 10.3.2)) for what to do in the first case (depends on the containing block). CSS images 3 defines a different behavior (use a default size).

I think it would be helpful to have a separate section about the automatic sizing of elements with intrinsic dimensions, and then the max-content-size definition should reference that. Or is the idea that another spec will define "auto size of replace elements is the max-content-size"? It's hard to figure out the overall context of any part of the spec: right now there are a lot of definitions and not a lot of prose connecting them together.

Sizing elements with intrinsic aspect ratio but neither intrinsic nor applied dimensions

(AKA, sizing SVG with a viewBox but width and height of auto)

CSS 2.1 says about inline, replaced elements (and then refers to this for replaced block and floating elements):

... the used value of 'width' is undefined in CSS 2.1. However, it is suggested that, if the containing block's width does not itself depend on the replaced element's width, then the used value of 'width' is calculated from the constraint equation used for block-level, non-replaced elements in normal flow.

The new CSS Sizing text for max-content-width is equivalent to that suggestion, updated to the new sizing terminology:

If the available space is definite in the inline axis, use the stretch fit into that size for the inline size and calculate the block size using the aspect ratio.

As mentioned, the way the spec is written the current text only applies this definition to max-content-size. But it is presumably supposed to be consistent with the general case of auto-sizing replaced elements.

However, this is not what browsers actually do for SVG. Instead, they always make the content-box inline-size 100%, ignoring borders and padding. I strongly believe that the "shrink-fit size" is a smarter behavior and that all the browsers are wrong--but please note that all the major browsers are currently consistent in their wrongness.

(P.S., the workaround is box-sizing: border-box; width: 100%)

And then there's the subject of #951: what to do when the available inline size is not definite.

Intrinsic sizes and aspect ratios and the box model

When discussing intrinsic aspect ratios and intrinsic sizes, it would be preferable to be explicit about which layout box they apply to, and that if necessary some values should be computed with padding and borders added or subtracted.

For SVG, the viewBox aspect ratio should logically be the content-box size, because the viewBox scale is based on the content-box size. For inline SVG, width and height will be affected by box-sizing, which may not be content-box; for other boxes, any aspect ratio calculations of width and height should logically take that into account. Current major browsers all do that when calculating width/height from a declared size in one dimension, but (as mentioned above) they don't do it for auto-sized SVG (in which case they always make the content-box 100%, regardless of box-sizing).

For embedded SVG documents, there is the added complication of the box model on the root element of the embedded document, which is separate from the borders and padding on the <img> or <object>. Most browsers currently position the root element within the image canvas to leave room for margin, padding, and borders (consistent with general rules for root elements and the box model), but do not adjust the intrinsic width, height, or aspect ratio to leave room for them. So the overall "intrinsic size" or "intrinsic aspect ratio" used to calculate the <img> or <object> size doesn't actually match the outer dimensions of the root <svg> in the embedded document. This is an SVG-specific thing that should probably be cleared up in SVG 2, by changing the "Intrinsic Sizing" section to explicitly mention the box model on the root element. (I'd thought we'd added a section about CSS backgrounds and borders on the top-level <svg>, but I can't seem to find it.) But worth mentioning here, because it is a mess.

Interaction of percentage sizing and intrinsic sizing

When creating tests for browser behavior for #951, I discovered that browsers can't agree on what do in the situation:

• a container is sized based on contents (e.g., a float)
• contents (inline size) are sized based on percentage of the container
• contents may or may not have an intrinsic aspect ratio or a defined block size

That sounds like something that should be defined in this spec, but maybe it's more appropriate for the general box model spec?

Why....?

Note: This specification does not define how to determine the size of a float. Please refer to [CSS2], the relevant CSS specification for that display type, and/or existing implementations for further details.

"Please refer to existing implementations for details"? This note raises more questions than it answers. Again, if you're going to make one spec dependent on another, can we please have links? Even if they have to be qualified by "or a future spec that replaces that section".

[fantasai]

Hehe, we can add some links, yes.

The reason we don't define things in detail is because that's a lot of work. In the case of images, the default sizing in CSS Images doesn't actually apply: replaced elements also have to account for min/max-width/height, which makes their sizing algorithm rather more complicated than for CSS images like backgrounds. You'll notice that in Examples of CSS Object Sizing replaced elements do not invoke the default sizing algorithm: this is why. We did not want to duplicate CSS2.1 here.

As for shrink-to-fit sizing in general, large aspects of that are undefined in CSS2.1, which is why the note about implementations. We're trying to avoid trying to fully define shrink-to-fit here by referencing CSS2.1 in the general interest of finishing the spec so that we have terminology and the new keywords available: we only require that the behavior of these new keywords and anywhere else that hooks into this behavior be consistent within a given implementation.

[fantasai]

@AmeliaBR OK, we added some links to CSS2.1, and added a paragraph explicitly replacing the undefined rule in 2.1 with the new max-content definition in css-sizing-3.

The Block and Inline Layout specification will eventually define what “auto” means for block-level and inline-level elements, but as it doesn't exist yet we're still relying on CSS2.1. Agreed it's a bit awkward, but hopefully we can make sure the definitions connect up here as best as we are able without rewriting most of 2.1.

Let us know if your comments seem sufficiently addressed, or if there are further edits we need to make.

Thanks!

[AmeliaBR]

@fantasai That's definitely an improvement, and probably as good as you can get it at this time, if you're hoping to keep the detailed descriptions of auto-sizing for a separate spec.