Design call: should an anchored rule preserve proportion or weight? #156

Closed
opened 2026-09-16 20:51:18 +00:00 by peterswimm · 0 comments
Owner

@ville — a genuine fork, deliberately not resolved in code. Both presses ship so you can see the difference rather than take my word for it.

anchor + extent (#154) let a pull occupy part of an element, which is what plate.ui.line-horizontal was drawn for — a hand-drawn rule at 33.6:1. Until #154 it was an orphan: registered, emitting a handle, referenced by no press, because the model could not hold it.

anchor and extent, auto vs fixed

The fork

Top row — extent: auto derives the band from the plate's own ratio: 11px at 360 wide, 19px at 640, 30px at 1024 (measured, not predicted). The drawing's proportions hold at any width — so the band's weight tracks the container. In a 1600px hero it is a 47px slab.

Bottom right — an explicit extent: 6 holds the weight and lets the proportions go. It is also lifted 12px off the edge by registration: [0, 12] alone, which is why placement needed no fourth field.

What I want decided

Which should a UI divider default to? Right now auto is the default for an anchored pull, on the reasoning that a derived number beats a guessed one. But a divider arguably wants constant weight — a hairline stays a hairline regardless of panel width.

This is the same anisotropy tension as #155, wearing a different coat: preserve the drawing, or preserve the mark. I do not think there is a right answer independent of what the rule is for.

Options as I see them:

  1. Keep auto as the default — proportions first; authors opt into a fixed weight.
  2. Flip the default to a fixed px — weight first; authors opt into auto for decorative bands.
  3. Split by intent — a divider preset vs a decorative-band preset, so the default follows the use rather than the field.

press.ruled-panel and press.ruled-panel-fixed ship one of each today, so whichever way you go there is already a working example to point at.

(Render pinned to #154's commit; that PR is green and awaiting merge.)

@ville — a genuine fork, deliberately not resolved in code. Both presses ship so you can see the difference rather than take my word for it. `anchor` + `extent` (#154) let a pull occupy **part** of an element, which is what `plate.ui.line-horizontal` was drawn for — a hand-drawn rule at **33.6:1**. Until #154 it was an orphan: registered, emitting a handle, referenced by no press, because the model could not hold it. ![anchor and extent, auto vs fixed](https://git.toilville.dev/Toilville/toilville-design/raw/commit/f001759/scratchpad/press-review/05-anchor.png) ## The fork **Top row — `extent: auto`** derives the band from the plate's own ratio: **11px at 360 wide, 19px at 640, 30px at 1024** (measured, not predicted). The *drawing's proportions* hold at any width — so the band's **weight tracks the container**. In a 1600px hero it is a 47px slab. **Bottom right — an explicit `extent: 6`** holds the **weight** and lets the proportions go. It is also lifted 12px off the edge by `registration: [0, 12]` alone, which is why placement needed no fourth field. ## What I want decided **Which should a UI divider default to?** Right now `auto` is the default for an anchored pull, on the reasoning that a derived number beats a guessed one. But a divider arguably wants constant weight — a hairline stays a hairline regardless of panel width. This is the same anisotropy tension as #155, wearing a different coat: *preserve the drawing, or preserve the mark.* I do not think there is a right answer independent of what the rule is **for**. Options as I see them: 1. **Keep `auto` as the default** — proportions first; authors opt into a fixed weight. 2. **Flip the default to a fixed px** — weight first; authors opt into `auto` for decorative bands. 3. **Split by intent** — a divider preset vs a decorative-band preset, so the default follows the use rather than the field. `press.ruled-panel` and `press.ruled-panel-fixed` ship one of each today, so whichever way you go there is already a working example to point at. *(Render pinned to #154's commit; that PR is green and awaiting merge.)*
Sign in to join this conversation.
No description provided.