Give the composer footer a bottom padding #240
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "fix/composer-footer-padding"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Three composers - the thread reply, the new message and the card notes - looked different from each other in ways nobody chose. This makes them one look, with per-consumer differences left as options rather than CSS.
What differed, measured
The inset is always the same sum: box padding + 1px border + 8px inner padding. Only the first term varied.
Three changes
One box padding.
Field.vuedefaulted to 8px where the other two use 4px.--field-paddingand--field-min-heightwere never overridden anywhere - knobs with no users that could only produce drift. Both removed, the value hardwired to 4px.One row height. The send button was 43px against 32px icon buttons. The centres lined up exactly, which is why it read as "the icons sit high" rather than "the button is tall": a row of controls is read on its bottom edge, and the filled pill set that edge 12px below the icons.
43px is not a size NLDD has (the scale is 24/32/44/56). It is what the button inherits from the body's 18px/27px after
d13909bremoved itsfont-size. Everything else in this footer is alreadysm, andsmis what the app uses for compact surfaces generally - 17 usages acrossFormatToolbar,DiscardButton,LinkBar,TargetPickerandToast- againstmdfor page and dialog actions. So the send button joins them rather than the row growing.One footer rule.
.composer-footerjoins.field-boxinbase.css.NotesEditorcarried only the top padding, so its toolbar sat on the border of its own box. It now gains the 8px under and beside it that the other two already had.Measured result
Box padding 8px to 4px, box height 131 to 113, send button 43 to 32. Both composers render identically; notes gains 8px of bottom air.
What this does not do
MessageEditorstill does not own the box, so the frame is declared per consumer. That is the next step and it is what makes this class of drift impossible rather than merely fixed. Rebased on #235, whoseFormatToolbarrewrite made part of the original plan unnecessary: the hand-rolled.headingand.moreBtncontrols it was going to resize no longer exist.Verification
vue-tsc, eslint (0 errors), vitest 692 in 95 files,vite build, release-script tests. Box padding, box height and button heights measured in Chromium on the built bundle.66a83cec49713fbb766750e75075b53b8007f832