Re: [csswg-drafts] [css-sizing-3] Mapping HTML’s IMG aspect-ratio behavior into CSS. (#4951)

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.`

<details><summary>The full IRC log of that discussion</summary>
&lt;AmeliaBR> Topic: Mapping HTML’s IMG aspect-ratio behavior into CSS<br>
&lt;astearns> github: https://github.com/w3c/csswg-drafts/issues/4951<br>
&lt;AmeliaBR> fantasai:<br>
&lt;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.<br>
&lt;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.<br>
&lt;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.<br>
&lt;AmeliaBR> ... There's more about sizing, but want to discuss that first.<br>
&lt;AmeliaBR> TabAtkins: That proposal, just allowing both parts together, sounds good for syntax.<br>
&lt;AmeliaBR> astearns: Any concerns about the concept separate from syntax.<br>
&lt;AmeliaBR> ??: Is it clear what it means for an intrinsic ratio to be available?<br>
&lt;AmeliaBR> TabAtkins: Once an image has loaded, it's available.<br>
&lt;astearns> s/??/smfr/<br>
&lt;AmeliaBR> astearns: I think we'd want to match HTML as much as possible.<br>
&lt;AmeliaBR> ??: Is it possible to define the aspect ratio directly by the attributes?<br>
&lt;AmeliaBR> fantasai: that's the idea<br>
&lt;astearns> s/??/cbiesinger/<br>
&lt;AmeliaBR> plinss: The width and height attri butes also affect the displayed size, don't they?<br>
&lt;AmeliaBR> fantasai: Yes, but that can be overridden in CSS.<br>
&lt;AmeliaBR> ... but the aspect ratio can help it set the correct layout box while also having one dimension responsive.<br>
&lt;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.<br>
&lt;AmeliaBR> q+<br>
&lt;astearns> zakim, open queue<br>
&lt;Zakim> ok, astearns, the speaker queue is open<br>
&lt;AmeliaBR> fantasai: So this issue is about matching the HTML behavior.<br>
&lt;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.<br>
&lt;florian> +1, +1<br>
&lt;AmeliaBR> My question was how does this affect things other than img?<br>
&lt;AmeliaBR> E.g., SVG?<br>
&lt;fremy> (+1 too fwiw)<br>
&lt;AmeliaBR> fantasai: It should affect anything that provides an intrinsic aspect ratio, that becomes the auto, other is fallback<br>
&lt;AmeliaBR> So, this could be a way to give a fallback for images with no intrinsic aspect ratio, too.<br>
&lt;AmeliaBR> fantasai: yes.<br>
&lt;AmeliaBR> astearns: I see lots of enthusiasm, any objections?<br>
&lt;AmeliaBR> RESOLVED: Add an aspect-ratio option that supports fallback from intrinsic ratio<br>
&lt;AmeliaBR> astearns: any concerns on syntax?<br>
&lt;AmeliaBR> RESOLVED: Use the `&lt;aspect-ratio>||auto` syntax<br>
&lt;AmeliaBR> fantasai: The other aspect of this is box sizing.<br>
&lt;r12a> s/atsushi: Calling from i18n wg/atsushi: Calling from i18n wg &amp; jlreq<br>
&lt;AmeliaBR> … We've defined that box-sizing affects the aspect ratio calculation (is it aspect of border box or content box)<br>
&lt;AmeliaBR> ... But for intrinsic aspect ratios, that only affects the content box. If it applied to border box, the results wouldn't work out.<br>
&lt;AmeliaBR> ... With this new syntax, if you're using image width &amp; height attributes, you always want that to affect content box<br>
&lt;AmeliaBR> ... Some options: If you use the auto keyword with a ratio, it always applies to the content box.<br>
&lt;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.<br>
&lt;tantek> I don't have an answer, just wanting to raise the question for consideration<br>
&lt;AmeliaBR> ... Or, take a keyword to determine which box applies.<br>
&lt;AmeliaBR> dbaron: Doesn't this also affect width and height of image from the elements?<br>
&lt;AmeliaBR> fantasai: Yes, I think so. But maybe less of an issue in a modern responsive layout where you're also using box-sizing.<br>
&lt;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 &amp; keyword could only affect ratio.<br>
&lt;AmeliaBR> florian: What about just always having box-sizing be used for explicit?<br>
&lt;AmeliaBR> fantasai: Because that wouldn't work for mapping attributes to an explicit ratio.<br>
&lt;fantasai> 1. aspect-ratio: &lt;ratio><br>
&lt;AmeliaBR> astearns: We could always have good defaults for now with option of adding keyword later.<br>
&lt;fantasai> 2. aspect-ratio: auto<br>
&lt;AmeliaBR> fantasai: We have three options (typing)<br>
&lt;fantasai> 3. aspect-ratio: auto &lt;ratio><br>
&lt;astearns> s/good defaults/defaults for html/<br>
&lt;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.<br>
&lt;fantasai> 4. aspect-ratio: auto &lt;ratio> content-box<br>
&lt;AmeliaBR> fantasai: So that would look like option 4<br>
&lt;fantasai> Behavior of 4 is required to map IMG. Whether it's equivalent to 3 is the question<br>
&lt;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<br>
&lt;AmeliaBR> cbiesinger: Could you clarify? How does the box affect the calculation?<br>
&lt;AmeliaBR> fantasai: The box size should be the one that matches the aspect ratio.<br>
&lt;AmeliaBR> astearns: So the mood is that the new syntax, with auto, always uses the content box. Any objections?<br>
&lt;AmeliaBR> RESOLVED: An aspect ratio specified with the auto option always applies to the content-box.<br>
&lt;AmeliaBR> astearns: We can decide later if a keyword is necessary.<br>
&lt;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<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4951#issuecomment-621337849 using your GitHub account

Received on Wednesday, 29 April 2020 16:58:15 UTC