The CV kind chip has almost no padding at its end, because .chip is shaped around a button it does not have #185

New issue

Closed

opened 2026-09-12 09:22:48 +00:00 by tiagoagueda · 1 comment

tiagoagueda commented

2026-09-12 09:22:48 +00:00

Owner

Observation

On Documents → CVs, the kind tag on each card sits hard against its own right edge. The
text nearly touches the border, and the chip reads lopsided next to the twelve pixels of
space on its left.

documents/cv_list.html:31:

<span class="chip py-0 text-xs"><span class="chip-text">{{ cv.get_kind_display }}</span></span>

Why

.chip is deliberately asymmetric. From app.css:

padding-inline-start: calc(var(--spacing) * 3);    /* 12px */
padding-inline-end:   calc(var(--spacing) * 0.5);  /*  2px */

Those two pixels are not a mistake — they are where the remove button goes. app.js
builds the chips it was designed for:

function chipFor(box, name, isNew, remove) {
  chip.className = isNew ? "chip chip-new" : "chip";
  text.className = "chip-text";
  button.className = "chip-remove";   /* 24px wide, flex-shrink-0 */

The button supplies the visual space at the end, so the class supplies almost none. A chip
without a button gets the 2px and nothing to fill it.

It is a trap, and one caller already fell into it and climbed out

Three places use .chip, and they disagree:

Where	Remove button	End padding
`app.js` `chipFor()`	yes	correct — the button fills it
`jobs/partials/company_row.html:40`	no	`class="chip py-0 pe-3 text-xs"` — patched by hand
`documents/cv_list.html:31`	no	nothing — this bug

Two of the three uses have no button. The company row's pe-3 is the same fix this needs,
written once already by somebody who hit the same thing and did not change the class.

Which suggests fixing the class, not the third caller

Adding pe-3 here would work and would leave the trap for the fourth caller. The shape
that matches how .chip is actually used is the opposite of what it does now:

.chip pads both ends properly, so a chip with only text is right by default.
.chip-remove — or a modifier alongside it — takes the end padding back, since the button
is the thing that replaces it.

Then company_row.html drops its pe-3 and cv_list.html needs no change at all.

Worth checking while in there

py-0 on both static chips overrides .chip's padding-block, so these are tighter
vertically than a chip is meant to be as well. The two static callers agree with each other
on that, so it may be deliberate; it is worth deciding rather than inheriting.
Right-to-left is already handled — the properties are logical (padding-inline-*), and the
fix must stay logical rather than becoming pr-3. CONTRIBUTING.md forbids the physical
utilities and the template lint enforces it.
The compiled stylesheet is committed and CI compares it, so this needs npm run build:css.

## Observation On *Documents → CVs*, the kind tag on each card sits hard against its own right edge. The text nearly touches the border, and the chip reads lopsided next to the twelve pixels of space on its left. `documents/cv_list.html:31`: <span class="chip py-0 text-xs"><span class="chip-text">{{ cv.get_kind_display }}</span></span> ## Why `.chip` is deliberately asymmetric. From `app.css`: padding-inline-start: calc(var(--spacing) * 3); /* 12px */ padding-inline-end: calc(var(--spacing) * 0.5); /* 2px */ Those two pixels are not a mistake — **they are where the remove button goes.** `app.js` builds the chips it was designed for: function chipFor(box, name, isNew, remove) { chip.className = isNew ? "chip chip-new" : "chip"; text.className = "chip-text"; button.className = "chip-remove"; /* 24px wide, flex-shrink-0 */ The button supplies the visual space at the end, so the class supplies almost none. A chip **without** a button gets the 2px and nothing to fill it. ## It is a trap, and one caller already fell into it and climbed out Three places use `.chip`, and they disagree: | Where | Remove button | End padding | | --- | --- | --- | | `app.js` `chipFor()` | yes | correct — the button fills it | | `jobs/partials/company_row.html:40` | no | `class="chip py-0 **pe-3** text-xs"` — patched by hand | | `documents/cv_list.html:31` | no | **nothing** — this bug | Two of the three uses have no button. The company row's `pe-3` is the same fix this needs, written once already by somebody who hit the same thing and did not change the class. ## Which suggests fixing the class, not the third caller Adding `pe-3` here would work and would leave the trap for the fourth caller. The shape that matches how `.chip` is actually used is the opposite of what it does now: - `.chip` pads **both** ends properly, so a chip with only text is right by default. - `.chip-remove` — or a modifier alongside it — takes the end padding back, since the button is the thing that replaces it. Then `company_row.html` drops its `pe-3` and `cv_list.html` needs no change at all. ## Worth checking while in there - `py-0` on both static chips overrides `.chip`'s `padding-block`, so these are tighter vertically than a chip is meant to be as well. The two static callers agree with each other on that, so it may be deliberate; it is worth deciding rather than inheriting. - Right-to-left is already handled — the properties are logical (`padding-inline-*`), and the fix must stay logical rather than becoming `pr-3`. `CONTRIBUTING.md` forbids the physical utilities and the template lint enforces it. - The compiled stylesheet is committed and CI compares it, so this needs `npm run build:css`.

tiagoagueda added the

bug

interface

tier

labels

2026-09-12 09:22:49 +00:00

tiagoagueda referenced this issue from a commit

2026-09-12 10:17:23 +00:00

Pad a chip at both ends, and let the button take its own space back

tiagoagueda commented

2026-09-12 11:57:17 +00:00

Author

Owner

Landed on 0.3.0 as 5adc95b27.

Fixed in the class rather than the third caller: a chip pads both ends and .chip-remove takes its own end back with -me-2.5. The company row's pe-3 workaround is gone, and the test that pinned ps-3/pe-0.5 now asserts the intent its own docstring states.

Landed on `0.3.0` as `5adc95b27`. Fixed in the class rather than the third caller: a chip pads both ends and `.chip-remove` takes its own end back with `-me-2.5`. The company row's `pe-3` workaround is gone, and the test that pinned `ps-3`/`pe-0.5` now asserts the intent its own docstring states.

tiagoagueda closed this issue

2026-09-12 11:57:17 +00:00