[css-anchor-position] `anchor()` Fallback type inconsistency vs WPT #10831

dshin-moz · 2024-09-03T19:56:13Z

For the anchor() function's optional fallback value, the spec text specifies <length-percentage>, but the corresponding WPT, anchor-parse-valid.html, considers the use of anchor() function itself to be valid, seemingly contradicting the spec text.

It seems to me that both the spec and the test were initially committed this way - Which one is correct?

The text was updated successfully, but these errors were encountered:

emilio · 2024-09-05T15:20:34Z

The spec seems clear, unless there's a strong cause to allow anchor() in the fallback?

cc @tabatkins @fantasai

dshin-moz · 2024-09-06T17:48:40Z

Also the case for anchor-size() - Fallback on spec is <length-percentage>, but WPT allows anchor-size().

bfgeek · 2024-09-09T23:01:56Z

So the fallback is somewhat desirable IMO, e.g. you can chain things together like:

right: anchor(--a left, anchor(--b left))

e.g. if "a" doesn't exist, use "b".

Note this is different than something like:
min(anchor(--a left), anchor(--b left)) as this will resolve the unknowns to zero, having an affect on the result.

dshin-moz · 2024-09-13T13:45:39Z

Hm, probably can draw an analogy to var() allowing multiple fallbacks through nesting..

1. WPT tests now accept `anchor-size()` property for sizing, inset, and margin properties [1]. 2. Adjust test expectations for `anchor-size()` fallbacks containing `anchor-size()` - This will need to be followed up once [2] is resolved. 3. Adjust expectations for devtools' auto-completion related mochitests. 4. We don't yet handle `anchor-size()` in `calc()`. [1] w3c/csswg-drafts#9827 [2] w3c/csswg-drafts#10831 Differential Revision: https://phabricator.services.mozilla.com/D222535 bugzilla-url: https://bugzilla.mozilla.org/show_bug.cgi?id=1900232 gecko-commit: a0bc0fe119dd86f4c51d31d2aadfa20133e0f595 gecko-reviewers: firefox-style-system-reviewers, devtools-reviewers, nchevobbe, emilio

…irefox-style-system-reviewers,devtools-reviewers,nchevobbe,emilio 1. WPT tests now accept `anchor-size()` property for sizing, inset, and margin properties [1]. 2. Adjust test expectations for `anchor-size()` fallbacks containing `anchor-size()` - This will need to be followed up once [2] is resolved. 3. Adjust expectations for devtools' auto-completion related mochitests. 4. We don't yet handle `anchor-size()` in `calc()`. [1] w3c/csswg-drafts#9827 [2] w3c/csswg-drafts#10831 Differential Revision: https://phabricator.services.mozilla.com/D222535

1. WPT tests now accept `anchor-size()` property for sizing, inset, and margin properties [1]. 2. Adjust test expectations for `anchor-size()` fallbacks containing `anchor-size()` - This will need to be followed up once [2] is resolved. 3. Adjust expectations for devtools' auto-completion related mochitests. 4. We don't yet handle `anchor-size()` in `calc()`. [1] w3c/csswg-drafts#9827 [2] w3c/csswg-drafts#10831 Differential Revision: https://phabricator.services.mozilla.com/D222535 bugzilla-url: https://bugzilla.mozilla.org/show_bug.cgi?id=1900232 gecko-commit: a0bc0fe119dd86f4c51d31d2aadfa20133e0f595 gecko-reviewers: firefox-style-system-reviewers, devtools-reviewers, nchevobbe, emilio

…irefox-style-system-reviewers,devtools-reviewers,nchevobbe,emilio 1. WPT tests now accept `anchor-size()` property for sizing, inset, and margin properties [1]. 2. Adjust test expectations for `anchor-size()` fallbacks containing `anchor-size()` - This will need to be followed up once [2] is resolved. 3. Adjust expectations for devtools' auto-completion related mochitests. 4. We don't yet handle `anchor-size()` in `calc()`. [1] w3c/csswg-drafts#9827 [2] w3c/csswg-drafts#10831 Differential Revision: https://phabricator.services.mozilla.com/D222535

…irefox-style-system-reviewers,devtools-reviewers,nchevobbe,emilio 1. WPT tests now accept `anchor-size()` property for sizing, inset, and margin properties [1]. 2. Adjust test expectations for `anchor-size()` fallbacks containing `anchor-size()` - This will need to be followed up once [2] is resolved. 3. Adjust expectations for devtools' auto-completion related mochitests. 4. We don't yet handle `anchor-size()` in `calc()`. [1] w3c/csswg-drafts#9827 [2] w3c/csswg-drafts#10831 Differential Revision: https://phabricator.services.mozilla.com/D222535 UltraBlame original commit: a0bc0fe119dd86f4c51d31d2aadfa20133e0f595

dshin-moz · 2024-09-26T13:51:33Z

So left: anchor(/* 1 */, anchor(/* 2 */)) would be different from

.anchored {
  left: anchor(/* 1 */);
  position-try-fallbacks: --fb;
}

@position-try --fb {
  left: anchor(/* 2 */);
}

The recursive fallback case will pick the option 1 so long as it's referring to a valid anchor, regardless of the absolute containing block overflowing, where the @position-try case will try option 2 if option 1 overflows the absolute containing block.

…irefox-style-system-reviewers,devtools-reviewers,nchevobbe,emilio 1. WPT tests now accept `anchor-size()` property for sizing, inset, and margin properties [1]. 2. Adjust test expectations for `anchor-size()` fallbacks containing `anchor-size()` - This will need to be followed up once [2] is resolved. 3. Adjust expectations for devtools' auto-completion related mochitests. 4. We don't yet handle `anchor-size()` in `calc()`. [1] w3c/csswg-drafts#9827 [2] w3c/csswg-drafts#10831 Differential Revision: https://phabricator.services.mozilla.com/D222535

dshin-moz · 2025-01-17T16:54:43Z

A testcase for my previous comment:

<!DOCTYPE html>
<style>
.container {
  position: relative;
  width: 100px;
  height: 100px;
  border: 1px solid;
}
.anchor {
  anchor-name: --foo;
  width: 100px;
  height: 10px;
  background: purple;
}

.positioned {
  position: absolute;
  width: 100px;
  height: 10px;
  background: pink;
  top: anchor(--foo bottom);
}

.recursive {
  left: anchor(--foo right, anchor(--foo left));
}

.fallback {
  left: anchor(--foo right);
  position-try-fallbacks: --fb;
}

@position-try --fb {
  left: anchor(--foo left);
}
</style>
<div class="container">
  <div class="anchor"></div>
  <div class="positioned recursive"></div>
</div>
<div class="container">
  <div class="anchor"></div>
  <div class="positioned fallback"></div>
</div>

On Chrome Version 134.0.6958.2 (Official Build) dev (64-bit), the first pink element positions to the lower right, where the second one positions directly below the anchor.

Both are fallbacks, but anchor() fallback does not consider overflow, where position-try-fallback does. That seems like a potential point of confusion.

tabatkins · 2025-01-22T17:04:11Z

Apologies for the late response, but as far as I can tell there's no inconsistency here. anchor() and anchor-size() are both defined to resolve to a <length>, so they're perfectly valid as <length-percentage> fallback values.

There's some additional restrictions on validity for the anchor functions, so they can't be used everywhere, but top: anchor(..., anchor(...)) is fine.

css-meeting-bot · 2025-01-22T18:02:02Z

The CSS Working Group just discussed [css-anchor-position] `anchor()` Fallback type inconsistency vs WPT, and agreed to the following:

RESOLVED: Close no change

The full IRC log of that discussion

<emilio> TabAtkins: in this issue it was raised that there's an inconsistency with the spec that says `<length-percentage>` on the fallback
<emilio> ... anchor and anchor-size are both `<length>`s
<emilio> ... so type wise they should be valid fallback
<emilio> ... so afaict there's no inconsistency
<emilio> RESOLVED: Close no change

dshin-moz · 2025-01-22T19:37:30Z

Ok - looking for a bit of additional clarification:

There's some additional restrictions on validity for the anchor functions so they can't be used everywhere [...]

I assume "additional restrictions" refer to to #9827 (Properties need to be compatible with interleaving)?
Even within those properties, we'd then follow the invalid case and potentially use the fallback (i.e. padding-left: anchor(--foo left, 10px) resolves to 10px)?

EDIT: Reasoning behind this ask is because the spec regarding validity currently seems to imply that "not being used in inset properties of abs-positioned box" is handled the same as "anchor it's referring to is not valid" - that is to say, use fallback if it exists, otherwise Invalid At Computed Value Time.

Chrome currently seems to treat failing the first part of the first validity condition as Invalid At Parse Time. OTOH, left: anchor(--foo left); with position: sticky resolves to fallback.

So hopefully the spec should be clarified on that. Though, I think there's some argument to be had about maybe being more web-compatible to be IACVT for unsupported properties, in case we end up supporting more?

dshin-moz · 2025-03-28T17:24:39Z

(Above question is probably better answered in #10950)

emilio added Agenda+ css-anchor-position-1 labels Sep 5, 2024

astearns moved this to TPAC/FTF agenda items in CSSWG Agenda TPAC 2024 Sep 13, 2024

astearns added this to CSSWG Agenda TPAC 2024 Sep 13, 2024

astearns moved this from TPAC/FTF agenda items to Regular agenda items in CSSWG Agenda TPAC 2024 Sep 13, 2024

moz-wptsync-bot mentioned this issue Sep 23, 2024

[Gecko Bug 1900232] Part 6 - Adjust test expectations for anchor-size. web-platform-tests/wpt#48307

Merged

css-meeting-bot removed the Agenda+ label Jan 22, 2025

mozilla-apprentice mentioned this issue Jan 22, 2025

[css-anchor-position] anchor() Fallback type inconsistency vs WPT mozilla/wg-decisions#1754

Closed

chromium-helper mentioned this issue Jan 22, 2025

[css-anchor-position] anchor() Fallback type inconsistency vs WPT chromium-helper/csswg-resolutions#651

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

[css-anchor-position] `anchor()` Fallback type inconsistency vs WPT #10831

[css-anchor-position] `anchor()` Fallback type inconsistency vs WPT #10831

dshin-moz commented Sep 3, 2024

emilio commented Sep 5, 2024

Uh oh!

dshin-moz commented Sep 6, 2024

Uh oh!

bfgeek commented Sep 9, 2024

Uh oh!

dshin-moz commented Sep 13, 2024

Uh oh!

dshin-moz commented Sep 26, 2024

Uh oh!

dshin-moz commented Jan 17, 2025

Uh oh!

tabatkins commented Jan 22, 2025

Uh oh!

css-meeting-bot commented Jan 22, 2025

Uh oh!

dshin-moz commented Jan 22, 2025 •

edited

Loading

Uh oh!

dshin-moz commented Mar 28, 2025

Uh oh!

[css-anchor-position] anchor() Fallback type inconsistency vs WPT #10831

[css-anchor-position] anchor() Fallback type inconsistency vs WPT #10831

Comments

dshin-moz commented Sep 3, 2024

emilio commented Sep 5, 2024

Uh oh!

dshin-moz commented Sep 6, 2024

Uh oh!

bfgeek commented Sep 9, 2024

Uh oh!

dshin-moz commented Sep 13, 2024

Uh oh!

dshin-moz commented Sep 26, 2024

Uh oh!

dshin-moz commented Jan 17, 2025

Uh oh!

tabatkins commented Jan 22, 2025

Uh oh!

css-meeting-bot commented Jan 22, 2025

Uh oh!

dshin-moz commented Jan 22, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dshin-moz commented Mar 28, 2025

Uh oh!

[css-anchor-position] `anchor()` Fallback type inconsistency vs WPT #10831

[css-anchor-position] `anchor()` Fallback type inconsistency vs WPT #10831

dshin-moz commented Jan 22, 2025 •

edited

Loading