Rules Hub
Coding Rules Library
Rule priority, scope & exceptions
Use this to align rules with the senior-level structure (P0/P1/P2, scope, exceptions/tradeoffs).
Keep dependent breakpoints in sync when one becomes dynamic
Two components sharing a hardcoded breakpoint must stay coordinated when one switches to a dynamic or conditional threshold.
Bad example
| 1 | // PanelA.module.scss |
| 2 | .panel { |
| 3 | container: panel / inline-size; |
| 4 | } |
| 5 | @container panel (max-width: 537px) { |
| 6 | .panel { flex-direction: column; } |
| 7 | } |
| 8 |
|
| 9 | // PanelB.module.scss (untouched sibling, still viewport-based) |
| 10 | @media (max-width: 537px) { |
| 11 | .dropdown { display: block; } // bottom sheet |
| 12 | } |
Explanation (EN)
PanelA was changed to react to its own container width (which can differ from the viewport by the surrounding margins/flags), but PanelB was left keyed to the raw viewport. They used to switch together at 537px; now they can disagree in a range of widths, producing a visibly mismatched layout.
Objašnjenje (HR)
PanelA je promijenjen da reagira na širinu vlastitog kontejnera (koja se može razlikovati od viewporta zbog marginalija/flagova), dok je PanelB ostao vezan uz sirovi viewport. Nekad su se prebacivali zajedno na 537px; sad se u rasponu širina mogu ne slagati, što daje vidljivo neusklađen layout.
Good example
| 1 | // shared/_breakpoints.scss |
| 2 | $panel-stack-breakpoint: 537px; |
| 3 |
|
| 4 | // PanelA.module.scss |
| 5 | @container panel (max-width: #{$panel-stack-breakpoint}) { ... } |
| 6 |
|
| 7 | // PanelB.module.scss |
| 8 | // Explicitly noted: intentionally viewport-based, not container-based, |
| 9 | // because it opens as a full-screen sheet independent of its parent's width. |
| 10 | @media (max-width: #{$panel-stack-breakpoint}) { ... } |
Explanation (EN)
Either drive both from one shared value/token so they always move together, or, if they must diverge (one is viewport-based, one is container-based on purpose), leave an explicit comment explaining the intentional split so a future change doesn't reintroduce the same silent drift by accident.
Objašnjenje (HR)
Ili obje vezati uz jednu zajedničku vrijednost/token da se uvijek mijenjaju zajedno, ili — ako se moraju razlikovati (jedna je vezana uz viewport, druga namjerno uz kontejner) — ostaviti eksplicitan komentar koji objašnjava tu namjernu razliku, da buduća promjena slučajno ne vrati isti tihi razmak.
Notes (EN)
This applies beyond CSS breakpoints too: any time two pieces of code (styles, feature flags, thresholds) are coupled by coincidence rather than a shared source, changing one side's condition can silently desync the other.
Bilješke (HR)
Ovo vrijedi i izvan CSS breakpointa: kad su dva dijela koda (stilovi, feature flagovi, pragovi) povezani slučajno, a ne preko zajedničkog izvora, promjena jednog uvjeta može tiho pokvariti sinkronizaciju s drugim.
Exceptions / Tradeoffs (EN)
If the two components are intentionally decoupled (one should react to viewport, the other to its own container) document why, since they can behave differently at some widths by design.
Iznimke / Tradeoffi (HR)
Ako su dvije komponente namjerno odvojene (jedna reagira na viewport, druga na svoj kontejner), zapiši zašto — po dizajnu se mogu ponašati različito na nekim širinama.