cancel_flex_item_centering( $styles, $base ); } /** * Cancel the shared width guard's `margin-left:auto;margin-right:auto` * (see StylesSchema::state_declarations()) wherever it actually fired. * * That guard exists to centre a narrower TOP-LEVEL block — a plain block * box, the only shape it was written for. This wrapper is `display: * inline-flex`, so in that normal-flow case the auto margins do nothing at * all: inline-level boxes never centre on their own horizontal margins. * They start doing something only once the wrapper becomes a Flex/Grid * ITEM of an Atomic Div/Flex/Grid parent — every value for a flex item's * own `display` computes to a block-level "outer display" regardless of * what was authored, which is exactly the size at which auto margins * start responding. And what they do there is take over the item's * position on the main axis outright — a flex item's own auto margins are * consulted before `justify-content` ever runs, so the parent's * Left/Center/Right stopped choosing anything: measured, `justify-content: * flex-start` and `flex-end` on the SAME 50px-wide icon with a Custom * Width rendered at the IDENTICAL centred position (277px from the left in * a 604px row either way) the moment the icon carried a width of its own. * * So the guard is worth exactly nothing for this block in the case it was * built for, and actively wrong in the one case it can ever reach. Rather * than touch the shared compiler both other guards on this block already * come from — and risk every OTHER atomic block that relies on it staying * centred inside a normal, non-flex parent — this walks the SAME compiled * buckets and, only where the guard actually wrote `auto` (never where an * author's OWN margin is what is there instead — `has_horizontal_margin()` * is what stopped the guard writing anything in that case, and this must * agree with it or an author's margin would be overwritten right back to * zero), resets it to `0` on the very same selector. Same specificity, * later in this block's own