From 27ba7587ceb0b2586c173189cc4c865b0ab1e373 Mon Sep 17 00:00:00 2001 From: Stephanie Hobson Date: Fri, 11 Sep 2026 10:56:28 -0700 Subject: [PATCH] Convert templates/ and nav/menu/footer family to logical properties (#1084) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Second pass of the logical-properties migration -- the templates/ and navigation/menu/footer component family, all built against current main (post mixed-decls merge), not the older WS-4 branch state. 59 of the 110 remaining @include bidi() calls removed: templates/_card-layout.scss (15 -> 0) _navigation.scss (11 -> 0) _footer.scss (10 -> 0) _menu-item.scss (6 -> 0) _menu.scss (5 -> 0) _menu-list.scss (4 -> 0) _sidebar-menu.scss (4 -> 0) templates/_main-with-sidebar.scss (4 -> 0) All eight files are now fully bidi()-free. Notable non-mechanical cases: - _navigation.scss / _menu-list.scss: several bidi() calls used the 3-value "same property, different value per direction" form in pairs (e.g. two separate (padding-left, X, 0) / (padding-right, 0, X) tuples) rather than one 4-value tuple. Same underlying swap pattern, just spelled differently -- traced each pair through by hand to confirm which logical property they resolve to. - _sidebar-menu.scss: one bidi() tuple paired a margin swap with a `transform: none / translateY(3px) rotate(180deg)` pair, flipping a ▸ triangle glyph to point the other way in RTL. transform has no logical/direction-aware equivalent (it's always in the element's own coordinate space), so that one stays an explicit [dir='rtl'] override -- only the margin half converted to margin-inline-start. - _navigation.scss: two `background-position` bidi() calls stay physical with [dir='rtl'] overrides (same policy as the select rule in E1 -- no safe logical keyword syntax for background-position across this browser matrix). One of the two also had a bidi() tuple that was identical in both directions (dead weight, a pure no-op) -- collapsed to a single plain declaration. - templates/_card-layout.scss, _menu.scss, _menu-item.scss: also converted several bare (non-bidi-wrapped) margin-left/margin-right:0 pairs to margin-inline: 0 -- these were plain symmetric physical declarations sitting right next to the bidi() calls, in scope for the same inline-axis cleanup even though they weren't wrapped in the mixin. Two real bugs found via a reported visual regression (menu-list component rendering padding: 0 24px 0 4px locally vs. production's padding: 0 24px 0 0) and fixed here, both the same class as the label.mzp-u-inline bug found in the E1 commit -- a full 4-value padding/margin shorthand implicitly zeroes every side it doesn't otherwise set, and replacing it with a single logical longhand drops that protection for the sides not touched: - _menu-list.scss's `.is-details .mzp-c-menu-list-title button`: the original bidi() call's LTR value was the full shorthand "0 (16px + $spacing-sm) 0 0", explicitly zeroing padding-top/bottom/ left. My conversion had only set padding-inline-end, so the button's padding-block and padding-inline-start fell through to the browser's UA default