fix(section): apply a block padding override to both axes - #187
Merged
Conversation
`padding: N` set the section's vertical padding and left the horizontal axis on the site default, so a block with an override rendered an asymmetric box -- 24px vertical against 48px horizontal at the default config. One number producing two values surprises authors, which is how this surfaced. Both axes now take the override, scoped to the inner content container: no override inner 48px all sides (site default, unchanged) padding: 4 inner 24px all sides padding: 0 inner 0px all sides The outer container keeps the site padding in every case, so an overridden section still lines its edge up with its neighbours -- all three fixture sections start at x=48 on desktop and x=16 on mobile, with identical outer padding. The author is repadding their content, not moving the section out of the page grid. The site-level mobile overrides are dropped with the values they refine. They exist to taper the *site* defaults, and an author naming one number for one section is not asking for a taper. At 390px with the site's `mobile.x = 3`, an unoverridden section renders 48px vertical / 16px horizontal while `padding: 4` renders 24px on all four sides -- and the outer container still tapers to 16px either way. This reverses the vertical-only scoping from #186, which avoided the horizontal axis because it also feeds the outer container. Splitting the two containers removes that constraint rather than trading against it. `pnpm test` passes: 40 pages, no errors. Verified on a 1119-page site across all three cases at 1440px and 390px.
markdumay
force-pushed
the
fix/symmetric-block-padding
branch
from
July 31, 2026 05:25
1a3e835 to
5d175fb
Compare
Contributor
Author
|
🎉 This PR is included in version 2.3.4 🎉 The release is available on GitHub release Your semantic-release bot 📦🚀 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-up to #186, which honoured
paddingonctaandpanelsbut applied it to the vertical axis only.Why that was wrong
One number producing two different values surprises authors. With the default config a block carrying
padding: 4rendered:— an asymmetric box, and the only section on its page off the site's rhythm. That is how this surfaced: a reviewer looked at the output and asked why
pxandpydisagreed.After
Both axes take the override, scoped to the inner content container:
padding: 4padding: 0The outer container keeps the site padding
This is the part that makes the horizontal axis safe to touch.
section.htmlbuilds two containers, and until now both derived theirxfrom the same value:The outer row is now identical in all three cases. Measured on a fixture page with all three side by side:
So an overridden section still lines up with its neighbours — the author is repadding their content, not moving the section out of the page grid.
#186 avoided the horizontal axis precisely because it fed the outer container. Splitting the two removes that constraint instead of trading against it.
Mobile overrides
The site-level taper is dropped along with the values it refines.
[main.padding.mobile]exists to taper the site defaults; an author naming one number for one section is not asking for a taper.At 390px with the site's
mobile.x = 3, an unoverridden section renders 48px vertical / 16px horizontal whilepadding: 4renders 24px on all four sides — and the outer container still tapers to 16px either way.Blast radius
Nothing on the sites I can check sets
paddingon actaorpanelsblock today — infusal.io removed the last of them in infusal/infusal.io#394, and it uses nopanels. So this changes the semantics for future use rather than moving anything currently rendered.Checks
pnpm testpasses: 40 pages, no errors. Verified on a 1119-page site across all three cases at 1440px and 390px.