[csswg-drafts] [css-grid] Replaced elements canvas, img, etc should behave as expected when styled with relative sizes in grid, transferred size should not affect them unless specifically asked to (#6278)

emilfihlman has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-grid] Replaced elements canvas, img, etc should behave as expected when styled with relative sizes in grid, transferred size should not affect them unless specifically asked to ==
Almost all the pictures you see on the web are scaled. This has been the case ever since we first saw images on displays. It is a very, very rare exception that you want to display raw raster data on the web exactly matched to the screen resolution. Yes, it happens and we do it often, but that's a fraction of our actual usage and in those instances it's most often a deliberate choice instead of the expectation.

Firefox currently implements this as expected, Chrome also did until recently. Additionally, a somewhat similar issue has already been discussed before: https://stackoverflow.com/questions/60206276/chrome-80-css-grid-large-descendants-cause-grid-to-grow and there it was decided that yes, this behaviour change is not acceptable to what developers expect.

And expectations matter. Yes, Chrome's interpretation is, apparently (though not all are entirely sure if it actually is) according to the spec, but if so, the spec is not what developers expect and is also not what we are taught from the most used references (and I stress, Firefox behaves as expected).

If you use a search engine to find help and examples on grid, you'll end up on

[A complete guide to Grid from css-tricks](https://css-tricks.com/snippets/css/complete-guide-grid/)

> "fraction of the free space in the grid (using the fr unit)"

> "The fr unit allows you to set the size of a track as a fraction of the free space of the grid container."

> "The free space is calculated after any non-flexible items. In this example the total amount of free space available to the fr units doesn’t include the 50px:"

or

[Basic concepts of grid layout from MDN](https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Grid_Layout/Basic_Concepts_of_Grid_Layout)

> "Tracks can be defined using any length unit. Grid also introduces an additional length unit to help us create flexible grid tracks. The new fr unit represents a fraction of the available space in the grid container. The next grid definition would create three equal width tracks that grow and shrink according to the available space."

> "In this final example, we mix absolute sized tracks with fraction units. The first track is 500 pixels, so the fixed width is taken away from the available space. The remaining space is divided into three and assigned in proportion to the two flexible tracks."

I'm going to venture and say that these two guides account for the vast majority of all grid documentation people look for.

Thus, if we have a page like this

````
<!doctype html>
<html>
 <head>
  <meta content="width=device-width, initial-scale=1.0, minimum-scale=1.0, maximum-scale=1.0, user-scalable=0" name="viewport" />
  <link rel="stylesheet" href="style.css" type="text/css" />
  <title>Grid img or canvas</title>
 </head>
 <body>
  <img>
  <section></section>
  <section></section>
  <section></section>
 </body>
</html>
````

with style

````
*
{
 font-family: monospace;
 box-sizing: border-box;
 margin: 0;
 padding: 1em;
 width: 100%;
 height: 100%;
}

body
{
 display: grid;
 gap: 1em;
 grid-template-columns: auto 1fr;
 grid-template-rows: 1fr auto;
 grid-template-areas: "section1 content"
    "section2 section3";
 justify-items: center;
 align-items: center;
 justify-content: center;
 align-content: center;
}

img
{
 grid-area: c;
 object-fit: contain;
}

section, img
{
 background-color: lightgreen;
}
````

[Live example](https://emil.fi/p/gridissue)

We absolutely expect that

1. the page doesn't scroll (no margins and all sizes for html, body, section and img are relative).

2. the image automatically occupies the assigned grid location and is contained (preserve aspect ratio, maximum fit to the container) to it.

However, this is not the case on Chrome, and the actual dimensions of the image today cause the image to break these two strong expectations. I stress the third time, Firefox currently behaves as expected, and Chrome did, too, until recently.

We can try to add contain: strict; (or just size) to the img tag, but this breaks the second expectation, aspect ratio is not preserved.

Styling pages should first follow logical expectations, that work on Firefox currently and break on Chrome after a recent change, and only after provide specific changes to augment the behaviour if needed. No reasonable developer would, after seeing this markup, expect these two assumptions 1 and 2 to break.

As mentioned, the core of the issue is transferred size. The behaviour is not logical, nor what is expected and the change in the draft causes regressions and breakage. object-fit already exists and perfectly describes the wanted behaviour.

The solution offered by Chrome "grid-template-rows: minmax(0, 1fr) auto;" is not consistent with the expectations of developers. If such additional behaviour is wanted, the extra should enable transferred size logic, but it should not be the default.

This must change.

[Issue tracker for Chrome](https://bugs.chromium.org/p/chromium/issues/detail?id=1183954) where this is marked as working as intended, it's a feature and WontFix.

Other attempts I did while debugging this issue that variously demonstrate the issue with a canvas element

https://emil.fi/p/gridscreen/
https://emil.fi/p/dynamiccanvas/
https://emil.fi/p/gridresize/
https://emil.fi/p/canvasgridresize/

Cheers

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6278 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Saturday, 8 May 2021 20:50:18 UTC