[{"data":1,"prerenderedAt":4},["ShallowReactive",2],{"post-content-css-logical-properties":3},"\u003Cp>\n  Here's a question most CSS developers can't answer about their own stylesheet: what does \u003Ccode>margin-left\u003C\u002Fcode> even mean? On a left-to-right page, it means \"the left edge.\" But rotate the writing direction and \"left\" stops being a meaningful concept. The physical properties (\u003Ccode>left\u003C\u002Fcode>, \u003Ccode>right\u003C\u002Fcode>, \u003Ccode>top\u003C\u002Fcode>, \u003Ccode>bottom\u003C\u002Fcode>) describe the screen. Logical properties describe the \u003Cem>content flow\u003C\u002Fem> — and content flow is what layout is actually about.\n\u003C\u002Fp>\n\n\u003Cp>\n  Logical properties are the modern way to write spacing, sizing, and borders. They're supported everywhere, they make RTL support nearly free, and they're one of those upgrades you do once and never think about again.\n\u003C\u002Fp>\n\n\u003Ch2>The mental model: inline and block\u003C\u002Fh2>\n\u003Cp>\n  Every element has two logical axes:\n\u003C\u002Fp>\n\u003Cul>\n  \u003Cli>\u003Cstrong>Inline axis\u003C\u002Fstrong> — the direction text flows. Left-to-right in English, right-to-left in Arabic and Hebrew.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Block axis\u003C\u002Fstrong> — the direction blocks stack. Top-to-bottom in most languages, with exceptions like Japanese vertical text.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>\n  Physical properties are relative to the screen. Logical properties are relative to these axes:\n\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-css\">margin-left     → margin-inline-start   \u002F* start of the inline axis *\u002F\nmargin-right    → margin-inline-end     \u002F* end of the inline axis *\u002F\nmargin-top      → margin-block-start    \u002F* start of the block axis *\u002F\nmargin-bottom   → margin-block-end      \u002F* end of the block axis *\u002F\n\npadding-left    → padding-inline-start\nborder-left     → border-inline-start\nwidth           → inline-size\nheight          → block-size\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>\n  The full mapping is large, but the pattern is one line to remember: \u003Cstrong>physical \"left\" becomes logical \"inline-start,\" physical \"top\" becomes \"block-start.\"\u003C\u002Fstrong> The rest falls out of that.\n\u003C\u002Fp>\n\n\u003Ch2>Why you should switch\u003C\u002Fh2>\n\n\u003Ch3>1. RTL support stops being a rewrite\u003C\u002Fh3>\n\u003Cp>\n  This is the headline reason. A sidebar with \u003Ccode>margin-left: 1rem\u003C\u002Fcode> needs a different rule in a right-to-left layout. With \u003Ccode>margin-inline-start: 1rem\u003C\u002Fcode>, the browser places the margin on the correct side automatically — no \u003Ccode>[dir=\"rtl\"]\u003C\u002Fcode> overrides, no mirrored stylesheet.\n\u003C\u002Fp>\n\u003Cp>\n  For products that ship in Arabic, Hebrew, or any RTL language, logical properties aren't a nicety; they're the difference between \"localization\" and \"building the layout twice.\"\n\u003C\u002Fp>\n\n\u003Ch3>2. Your \"left\" might be someone's \"right\"\u003C\u002Fh3>\n\u003Cp>\n  Even without full RTL support, mixing direction in a UI — a rail, a drawer, a flipped dashboard — becomes far less painful when you're describing content flow instead of screen coordinates.\n\u003C\u002Fp>\n\n\u003Ch3>3. It documents intent\u003C\u002Fh3>\n\u003Cp>\n  \u003Ccode>margin-inline-start\u003C\u002Fcode> tells the reader \"this spacing is about content flow, not screen position.\" That's a real signal in a codebase, and it makes refactoring safer.\n\u003C\u002Fp>\n\n\u003Ch2>Practical gotchas\u003C\u002Fh2>\n\n\u003Ch3>1. Some properties have no logical version yet\u003C\u002Fh3>\n\u003Cp>\n  \u003Ccode>border-radius\u003C\u002Fcode> got logical longhands (\u003Ccode>border-start-start-radius\u003C\u002Fcode>, etc.) that are verbose and rarely worth it. \u003Ccode>transform\u003C\u002Fcode> and \u003Ccode>position\u003C\u002Fcode> offsets are also still physical in most cases. Use logical properties where the mapping is clean (margin, padding, inset, size) and don't force it where the names get absurd.\n\u003C\u002Fp>\n\n\u003Ch3>2. \u003Ccode>inset\u003C\u002Fcode> is the shorthand that helps\u003C\u002Fh3>\n\u003Cpre>\u003Ccode class=\"language-css\">\u002F* physical *\u002F\ntop: 0; right: 0; bottom: 0; left: 0;\n\u002F* logical *\u002F\ninset: 0;\n\ninset-block: 0;     \u002F* top and bottom *\u002F\ninset-inline: 0;    \u002F* left and right *\u002F\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>\n  For absolute positioning, \u003Ccode>inset-inline\u003C\u002Fcode> and \u003Ccode>inset-block\u003C\u002Fcode> cover most cases and read much better than four physical properties.\n\u003C\u002Fp>\n\n\u003Ch3>3. Default writing mode still works\u003C\u002Fh3>\n\u003Cp>\n  In a default \u003Ccode>writing-mode: horizontal-tb\u003C\u002Fcode> context, logical and physical properties produce identical results for LTR content. The switch is invisible to your current users — it only changes behavior when direction or writing mode changes. That's the whole point: you future-proof without changing today's output.\n\u003C\u002Fp>\n\n\u003Ch2>Browser support\u003C\u002Fh2>\n\u003Cp>\n  Logical properties have been baseline since 2020 (Chrome 87, Safari 14.1, Firefox 66). There's no compatibility excuse left — every browser your users run supports them, and the fallback story is just \"use physical properties if you need ancient support.\"\n\u003C\u002Fp>\n\n\u003Ch2>Where it sits in the modern CSS stack\u003C\u002Fh2>\n\u003Cp>\n  Logical properties are the quiet foundation of modern CSS. They're less flashy than \u003Ca href=\"\u002Fposts\u002Fcss-container-queries-guide\u002F\">container queries\u003C\u002Fa> or \u003Ca href=\"\u002Fposts\u002Fcss-has-selector-parent-selector\u002F\">:has()\u003C\u002Fa>, but they change how every layout you write behaves. Pair them with \u003Ca href=\"\u002Fposts\u002Fcss-cascade-layers\u002F\">cascade layers\u003C\u002Fa> for priority and you have a layout system that's direction-aware and specificity-sane.\n\u003C\u002Fp>\n\u003Cp>\n  When I do a migration like this, I save the mapping table and the patterns that work in \u003Ca href=\"https:\u002F\u002Fdevspera.com\u002Fsnippetark\u002F\" target=\"_blank\">Snippet Ark\u003C\u002Fa> — the \"physical to logical\" cheat sheet is exactly the kind of thing you don't want to re-derive mid-project.\n\u003C\u002Fp>\n\n\u003Ch2>The bottom line\u003C\u002Fh2>\n\u003Cp>\n  Logical properties describe layout the way layout actually works — as content flowing through axes, not coordinates on a screen. They cost nothing to adopt, make RTL support a rounding error instead of a project, and force you to think about writing direction from day one. If you only do one CSS modernization this year, do this one first.\n\u003C\u002Fp>\n",1787812702636]