Re: [csswg-drafts] [css-anchor-position] `anchor-size()` should fallback to `auto`, not zero (#10005)

The CSS Working Group just discussed ``[css-anchor-position] `anchor-size()` should fallback to `auto`, not zero``, and agreed to the following:

* `RESOLVED: if an anchor-size can't resolve and doesn't have a fallback, then it is ICVT`
* `RESOLVED: if an anchor() can't resolve and doesn't have a fallback, then it is ICVT`

<details><summary>The full IRC log of that discussion</summary>
&lt;chrishtr> TabAtkins: currently the anchor pos spec says that an anchor-size refers to an invalid anchor then it resolves to 0px. We do the same with the anchor function.<br>
&lt;chrishtr> TabAtkins: fantasai pointed out that for anchor-size in particular this doesn't seem ideal, and would result in a broken page. Suggestion originally proposed was to resolve to auto if there is no valid fallback.<br>
&lt;chrishtr> TabAtkins: later in the thread there was a proposal to describe it as invalid instead of auto, to simplify things. This seems fine to me.<br>
&lt;chrishtr> TabAtkins: there would have had to be special cases though if we went with auto, so invalid is more complete and consistent IMO<br>
&lt;fantasai> sgtm<br>
&lt;Rossen__> q?<br>
&lt;chrishtr> TabAtkins: propose that we go with the "invalid" definition.<br>
&lt;chrishtr> +1 to proposed resolution<br>
&lt;kizu> ICVT sounds good<br>
&lt;TabAtkins> "invalid at computed-value time", specifically<br>
&lt;fantasai> s/invalid instead/"invalid at computed value time" instead/<br>
&lt;chrishtr> emilio: this would be a first case of that happening, which is a bit odd.<br>
&lt;chrishtr> TabAtkins: otherwise calc that contains anchor-size would remove and go to auto; the cyclic cases in other places also were defined to do that<br>
&lt;chrishtr> emilio: if the developer passes auto to calc-size explicitly then it should work once that is defined right?<br>
&lt;emilio> Instead of calc-size(anchor-size(&lt;invalid>) + 20px), calc-size(auto + 20px)<br>
&lt;chrishtr> TabAtkins: auto is fine in calc-size, but that doesn't allow you to put it in arbitrary locations when it can't resolve to a length<br>
&lt;chrishtr> emilio: ok then I'm fine with the ICVT definition<br>
&lt;chrishtr> proposed resolution: if an anchor-size can't resolve and doesn't have a fallback, then it is ICVT<br>
&lt;chrishtr> RESOLVED: if an anchor-size can't resolve and doesn't have a fallback, then it is ICVT<br>
&lt;chrishtr> TabAtkins: anchor makes a bit more sense than anchor-size to resolve to 0px, but for consistency perhaps we should align with the anchor-size resolution<br>
&lt;chrishtr> TabAtkins: propose that we apply the same resolution to the anchor() function as well<br>
&lt;chrishtr> RESOLVED: if an anchor() can't resolve and doesn't have a fallback, then it is ICVT<br>
</details>


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


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

Received on Wednesday, 10 April 2024 16:14:34 UTC