After switching a page to direction: rtl, which CSS declarations keep pointing the same physical way even when every box property has been converted to logical form?

## What the abstraction covers The CSS Logical Properties and Values specification re-expresses the *box model* in flow-relative terms. Everything it covers mirrors automatically when `direction` flips: - `margin-inline-start/end`, `padding-inline-start/end` - `border-inline-start` and its `-width`, `-style`, `-color` long-hands - `inset-inline-start/end` - `inline-size`, `min-inline-size`, `max-inline-size` - the logical corners `border-start-start-radius`, `border-start-end-radius`, `border-end-start-radius`, `border-end-end-radius` - flow-relative *values* like `text-align: start` and `text-align: end` Layout algorithms also honour direction on their own: in Flexbox and Grid the inline axis follows `direction`, so a row of items really does reverse for a right-to-left locale without any per-locale CSS. ## What stays stubbornly physical Everything outside the box model. These are the ones that reliably survive a "we converted everything" claim and show up as visual bugs in the right-to-left build: 1. **Shadows.** `box-shadow: 4px 0 8px rgba(0,0,0,.3)` casts to the right in both directions. So does `text-shadow`. There is no logical offset syntax. 2. **Transforms.** `transform: translateX(20px)` moves right in Arabic too. `rotate()` turns the same way, which matters for chevrons and disclosure arrows. `transform-origin: left top` is physical. 3. **Backgrounds.** `background-position: left 10px center` and the `background-position-x` longhand are physical, as are the gradient direction keywords in `linear-gradient(to right, …)` and explicit angles. 4. **Physical radii.** `border-top-left-radius` does not mirror; only the logical corner names do. 5. **Leftover physical box properties.** Anything the migration missed — including the four-value `margin`, `padding` and `inset` shorthands, which have no logical equivalent and stay in top/right/bottom/left order. 6. **Physical alignment values.** `text-align: left`, `float: left`, `clear: right` — the flow-relative values exist (`start`, `end`, `inline-start`, `inline-end`) but you have to actually use them. 7. **Masks and clipping.** `clip-path: polygon(...)` coordinates and mask positions are raw geometry with no notion of flow. 8. **Non-CSS content.** Directional artwork — back arrows, indent icons, chart glyphs — lives in markup or assets and needs its own mirroring decision. ## Why this is the real senior question Anyone can recite the property list. The judgement being probed is whether you know that logical properties get you most of the way and then stop, and that the remaining surface is exactly the decorative layer nobody writes tests for. A component can pass a mechanical audit — zero physical margins — and still render a shadow on the wrong side, a chevron pointing the wrong way, and a gradient that fades toward the wrong edge. ## How to handle the remainder **Custom properties as the flip point.** Route the physical bits through a variable and swap it once per direction: ```css :root { --dir-x: 1; } :root:dir(rtl) { --dir-x: -1; } .card { box-shadow: calc(4px * var(--dir-x)) 0 8px rgba(0, 0, 0, .3); } .chevron { transform: scaleX(var(--dir-x)); } ``` The `:dir()` pseudo-class matches an element by its resolved direction; an `[dir="rtl"]` attribute selector is the more conservative equivalent where broader support matters. **Mirror wholesale where it is safe.** `transform: scaleX(-1)` on a purely directional icon flips it correctly in one declaration — but never apply it to anything containing text or a brand mark. **Audit visually, not just mechanically.** Run the interface in a right-to-left locale and look at it. Grep can find `margin-left`; only a human notices that the elevation now reads as coming from the wrong side of the room. **Third-party CSS.** Vendor stylesheets are usually physical and out of your control. Either process them through a mirroring step or override the specific offenders in a later cascade layer. Logical box properties, including the logical corner radii, are supported across all current browsers, so the constraint here is coverage of the specification's scope — not browser support.