Re: [csswg-drafts] [css-sizing] Intrinsic Size of Images with Intrinsic Aspect Ratio and No Size

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](https://drafts.csswg.org/css-sizing-3/#intrinsic-sizes):


## 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)](https://www.w3.org/TR/CSS2/visudet.html#inline-replaced-width)) for what to do in the first case (depends on the containing block).  [CSS images 3](https://drafts.csswg.org/css-images/#object-negotiation) 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](https://svgwg.org/svg2-draft/coords.html#SizingSVGInCSS) 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".

-- 
GitHub Notification of comment by AmeliaBR
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1609#issuecomment-319275499 using your GitHub account

Received on Tuesday, 1 August 2017 05:55:13 UTC