[css-sizing-3] Mapping HTML’s IMG aspect-ratio behavior into CSS.

[fantasai]

HTML accepted to map the width and height attributes of the IMG element (and some others) to an aspect ratio for the purpose of rendering in whatwg/html#4952 . Currently this is specified as providing an “intrinsic aspect ratio” until the image loads and is able to provide its own. Since the current aspect-ratio property doesn't have a way to indicate "use this value until the element can provide its own", the behavior can't be mapped directly to CSS.

But we do prefer having rendering rules mappable to CSS, so the question is how should we make this possible? The two questions are:

1. What syntax to use to indicate "here's an aspect ratio to use but only until the thing loads and provides its own info"?
2. How do we handle the nuances of box-sizing? Currently an explicit aspect ratio (<ratio>) uses the specified box, whereas an intrinsic one (auto) uses content-box always. Probably the IMG mapping should continue to use content-box always. Is this a function of the above-mentioned syntax, or an extra switch?

Wrt 1, I suggest just allowing the auto and <ratio> values to be combined. (The current syntax is auto | <ratio>, this would make it auto || <ratio> with the combined value treating <ratio> as fallback only.)

Wrt 2, we could consider one or both of:

• Combining auto and <ratio> triggers using content-box always.
• Add an optional box-sizing keyword into the syntax, e.g. auto || <ratio> || <visual-box>.

My inclination is to do both.

[css-meeting-bot]

The CSS Working Group just discussed Mapping HTML’s IMG aspect-ratio behavior into CSS, and agreed to the following:

• RESOLVED: Add an aspect-ratio option that supports fallback from intrinsic ratio
• RESOLVED: Use the `<aspect-ratio>||auto` syntax
• RESOLVED: An aspect ratio specified with the auto option always applies to the content-box.

The full IRC log of that discussion

<AmeliaBR> Topic: Mapping HTML’s IMG aspect-ratio behavior into CSS
<astearns> github: https://github.com//issues/4951
<AmeliaBR> fantasai:
<AmeliaBR> fantasai: This is about the new behavior in the HTML spec about using the img attributes for height and width, and use that as the aspect ratio until the image loads.
<AmeliaBR> ... We'd like to map this to the aspect-ratio property, but that property currently overrides intrinsic aspect ratio, so wouldn't fall back once the image loads.
<AmeliaBR> ... Proposal is to add a new syntax that allows you set both auto and a numeric ratio, so that auto is used if element has an intrinsic ratio.
<AmeliaBR> ... There's more about sizing, but want to discuss that first.
<AmeliaBR> TabAtkins: That proposal, just allowing both parts together, sounds good for syntax.
<AmeliaBR> astearns: Any concerns about the concept separate from syntax.
<AmeliaBR> ??: Is it clear what it means for an intrinsic ratio to be available?
<AmeliaBR> TabAtkins: Once an image has loaded, it's available.
<astearns> s/??/smfr/
<AmeliaBR> astearns: I think we'd want to match HTML as much as possible.
<AmeliaBR> ??: Is it possible to define the aspect ratio directly by the attributes?
<AmeliaBR> fantasai: that's the idea
<astearns> s/??/cbiesinger/
<AmeliaBR> plinss: The width and height attri butes also affect the displayed size, don't they?
<AmeliaBR> fantasai: Yes, but that can be overridden in CSS.
<AmeliaBR> ... but the aspect ratio can help it set the correct layout box while also having one dimension responsive.
<AmeliaBR> florian: Both the width/height and the aspect ratio would be based on HTML attributes, but independently, so one could be overridden but not the other.
<AmeliaBR> q+
<astearns> zakim, open queue
<Zakim> ok, astearns, the speaker queue is open
<AmeliaBR> fantasai: So this issue is about matching the HTML behavior.
<dbaron> I wonder why we don't �also� map the width and height attributes to the intrinsic width and intrinsic height for not-yet-loaded images.
<florian> +1, +1
<AmeliaBR> My question was how does this affect things other than img?
<AmeliaBR> E.g., SVG?
<fremy> (+1 too fwiw)
<AmeliaBR> fantasai: It should affect anything that provides an intrinsic aspect ratio, that becomes the auto, other is fallback
<AmeliaBR> So, this could be a way to give a fallback for images with no intrinsic aspect ratio, too.
<AmeliaBR> fantasai: yes.
<AmeliaBR> astearns: I see lots of enthusiasm, any objections?
<AmeliaBR> RESOLVED: Add an aspect-ratio option that supports fallback from intrinsic ratio
<AmeliaBR> astearns: any concerns on syntax?
<AmeliaBR> RESOLVED: Use the `<aspect-ratio>||auto` syntax
<AmeliaBR> fantasai: The other aspect of this is box sizing.
<r12a> s/atsushi: Calling from i18n wg/atsushi: Calling from i18n wg & jlreq
<AmeliaBR> … We've defined that box-sizing affects the aspect ratio calculation (is it aspect of border box or content box)
<AmeliaBR> ... But for intrinsic aspect ratios, that only affects the content box. If it applied to border box, the results wouldn't work out.
<AmeliaBR> ... With this new syntax, if you're using image width & height attributes, you always want that to affect content box
<AmeliaBR> ... Some options: If you use the auto keyword with a ratio, it always applies to the content box.
<tantek> I'm wondering if that assertion (you don't want to include the border in the aspect ratio) is true for form-control like things, whether actual replaced form control elements, or images being made to look like form controls.
<tantek> I don't have an answer, just wanting to raise the question for consideration
<AmeliaBR> ... Or, take a keyword to determine which box applies.
<AmeliaBR> dbaron: Doesn't this also affect width and height of image from the elements?
<AmeliaBR> fantasai: Yes, I think so. But maybe less of an issue in a modern responsive layout where you're also using box-sizing.
<AmeliaBR> ... I can't see a reason you'd want intrinsic sizes to affect the border-box. But I can imagine wanting an explict ratio to affect border-box. So auto could always be intrinsic & keyword could only affect ratio.
<AmeliaBR> florian: What about just always having box-sizing be used for explicit?
<AmeliaBR> fantasai: Because that wouldn't work for mapping attributes to an explicit ratio.
<fantasai> 1. aspect-ratio: <ratio>
<AmeliaBR> astearns: We could always have good defaults for now with option of adding keyword later.
<fantasai> 2. aspect-ratio: auto
<AmeliaBR> fantasai: We have three options (typing)
<fantasai> 3. aspect-ratio: auto <ratio>
<astearns> s/good defaults/defaults for html/
<AmeliaBR> fantasai: in case of explicit ratio only, there's a good argument for matching box-sizing. For auto, needs to match content-box always. For third case (fallback), that's the issue. Should explicit ratio apply to content box, despite normal behavior, because of auto. Or we can match box-sizing, but have a syntax for switching to content-box.
<fantasai> 4. aspect-ratio: auto <ratio> content-box
<AmeliaBR> fantasai: So that would look like option 4
<fantasai> Behavior of 4 is required to map IMG. Whether it's equivalent to 3 is the question
<AmeliaBR> fremy: I can't see any case where you'd want to use auto and not want the content-box. So I think it's solved by saying the auto keyword means content-box
<AmeliaBR> cbiesinger: Could you clarify? How does the box affect the calculation?
<AmeliaBR> fantasai: The box size should be the one that matches the aspect ratio.
<AmeliaBR> astearns: So the mood is that the new syntax, with auto, always uses the content box. Any objections?
<AmeliaBR> RESOLVED: An aspect ratio specified with the auto option always applies to the content-box.
<AmeliaBR> astearns: We can decide later if a keyword is necessary.
<tantek> I ok with prototyping it that way and quickly seeking feedback on how it interacts with box-sizing of other things in the layout