[BUG] `inset` not overridden correctly in fallbacks

[jamesnw]

Describe the bug
Given

 inset: auto;
 top: anchor(bottom);
 left: anchor(right);

the position-try fallback is created as:

  left:var(--anchor-15OcXs-HWJ-Q)!important;
  top:revert!important;
  bottom:var(--anchor-NFBDsMuRrZSb)!important;
  inset:auto!important;

The inset is added after the others, which cascades to override the other values. In addition, top conflicts, and should not be set.

To Reproduce
Create a target with position-try-fallbacks and inset: auto.

Expected behavior
The inset shorthand should work in combination with the other values as expected.

Screenshots
If applicable, add screenshots to help explain your problem.

Browsers tested on
Polyfill v0.5.1

[freshyill]

I think this is broader than the title suggests. position-try-fallbacks isn't needed. A plain rule with inset: auto followed by anchor() insets is all it needs to fail.

I tested in Firefox 152 with layout.css.anchor-positioning.enabled = false.

In my test (CodePen link), I have div.wrap, which has 100px padding on either side. Inside is div.band. Then div.panel should be anchored to it.

/* A — panel 0 → 66      ✗ does not span */
.panel {
  position: fixed;
  inset: auto;                                /* reset the [popover] UA inset: 0 */
  inset-block-start:  anchor(--band end);
  inset-inline-start: anchor(--band start);
  inset-inline-end:   anchor(--band end);
  inline-size: auto;
}

/* B — panel 100 → 800   ✓ spans, `inset: auto` deleted            */
/* C — panel 100 → 800   ✓ spans, `top/right/bottom/left: auto`    */

Deleting that one declaration is the whole difference. In every case the polyfill writes identical, correct custom properties. The anchor values are never wrong; they just get overridden.

expandInsetShorthands() in src/cascade.ts expands the shorthand with block.children.appendData(...), which appends the longhands to the end of the rule regardless of where the shorthand appeared in source. The installed rule becomes:

.panel{position:fixed;inset:auto;
  inset-block-start:var(--anchor-…);
  inset-inline-start:var(--anchor-…);
  inset-inline-end:var(--anchor-…);
  inline-size:auto;
  top:auto;right:auto;bottom:auto;left:auto;   /* ← appended, wins on source order */
}

Physical and logical longhands resolve to the same properties, so the appended autos win. Trigger conditions measured: inset: auto breaks both axes; inset: 0 breaks both; inset-inline: auto breaks only the inline axis; inset-block: auto only the block axis. A shorthand in a separate earlier rule is harmless.

inset: auto seems like the natural way to reset the [popover] UA inset: 0 before applying anchor() insets, so it shows up in popover-anchored panels, which seems like a common case.

The longhand workaround doesn't survive minification. C looks like a clean fix but LightningCSS 1.32.0 collapses top/right/bottom/left: auto straight back into inset: auto and hoists it above the anchor longhands. Authoring the longhands in source doesn't reach the browser. (Native engines are unaffected: the hoisting puts inset:auto before the anchor longhands, which is the order native needs.) I'm guessing other minifiers will do the same. A workaround that does work with minification is to reset only the specific side you need — e.g. inset-block-end: auto alone — since there's then no shorthand to collapse or expand.

Happy to test a fix if that helps.

[jamesnw]

@freshyill Thanks for reporting! I think that's a similar bug, with a separate cause. I split it into a separate bug.

The fallbacks bug appears to be caused by how the CSS block is generated for each fallback, and not by appendData in expandInsetShorthands().