Media query senza media query? Come potrebbero cambiare presto le condizioni in CSS

Perché potremmo scrivere responsive in modo diverso

Le media query “classiche” sono ormai un pattern standard: definisci uno stile base e poi lo modifichi con un blocco @media ripetendo (spesso) il selettore.

Negli ultimi tempi, però, CSS sta andando nella direzione di ridurre boilerplate e rendere il codice più espressivo vicino al punto in cui serve. Il risultato è che il responsive potrebbe spostarsi:

• da blocchi separati (@media)…
• a condizioni integrate nella definizione delle regole o addirittura nei valori.

Vediamo tre step, dal “già utilizzabile” al “molto promettente ma da monitorare”.

---

1) Il miglioramento immediato: nesting per evitare di ripetere selettori

Se stai scrivendo qualcosa del tipo:

.cards {
  display: flex;
  flex-direction: column;
}

@media (width > 600px) {
  .cards {
    flex-direction: row;
  }
}

il problema non è tanto la media query, quanto la ripetizione di .cards.

Con il nesting (ormai una realtà concreta nel CSS moderno), puoi “portare” la media query dentro la regola:

.cards {
  display: flex;
  flex-direction: column;

  @media (width > 600px) {
    flex-direction: row;
  }
}

Perché è interessante

• Riduce duplicazioni.
• Tiene vicini stile base e variazioni responsive.
• Migliora la scansionabilità del file: leggi il componente in un unico blocco.

---

2) Valori condizionali: cambiare una proprietà “inline”

Quando l’unica differenza tra breakpoint è una sola proprietà, i blocchi @media possono sembrare eccessivi.

Sta emergendo l’idea di usare una funzione condizionale (stile if) direttamente nel valore:

.cards {
  display: flex;
  flex-direction: if((width > 600px): row; else: column);
}

Pro e contro

Pro

• Lo “switch” è vicino alla proprietà che cambia.
• Puoi eliminare blocchi dedicati quando la variazione è minimale.

Contro

• La leggibilità può peggiorare: molte persone non si aspettano logica nel valore.
• Il supporto cross-browser è un punto critico: ad oggi va considerata una funzionalità da usare con cautela.

In pratica: è un’idea potente, ma prima di adottarla in produzione serve valutare compatibilità e team readability.

---

3) Funzioni CSS: incapsulare breakpoint e rendere il codice più leggibile

Se la sintassi condizionale “inline” ti sembra troppo densa, c’è un’evoluzione naturale: astrarre la condizione.

L’approccio è definire una funzione CSS (es. @function) che riceve due valori (narrow/wide) e restituisce quello corretto in base al breakpoint.

Esempio concettuale:

@function mq-small(narrow, wide) {
  result: if((width > 600px): wide; else: narrow);
}

.cards {
  display: flex;
  flex-direction: mq-small(column, row);
}

Cosa cambia davvero

• Il breakpoint vive in un posto solo (la funzione).
• Il componente resta pulito: leggi mq-small(column, row) e capisci l’intenzione.
• Puoi standardizzare un set di breakpoint condivisi dal progetto.

È un approccio simile (per spirito) alle variabili di design system: sposti la complessità in una primitive riusabile.

---

Come cambia la mentalità (più che la sintassi)

Queste evoluzioni puntano tutte alla stessa direzione:

1. Ridurre ripetizioni (nesting).
2. Avvicinare la logica al punto d’uso (valori condizionali).
3. Centralizzare le regole in primitive riusabili (funzioni).

Il risultato è un CSS che sembra meno “a blocchi” e più “espressivo”: il responsive non è più solo un secondo passaggio, ma parte della definizione stessa della regola.

---

Cosa fare oggi

• Nesting: se il tuo target browser lo consente, è già un miglioramento pragmatico e generalmente leggibile.
• Valori condizionali e funzioni: tienili d’occhio. Prima di usarli in produzione, verifica supporto e valuta l’impatto sulla chiarezza del codice del team.

Se questa traiettoria si consolida, tra non molto potremmo scrivere responsive senza “pensare” in termini di media query come blocchi separati, ma come scelte localizzate nei valori e nelle primitive del progetto.