Device Posture e Viewport Segments in Safari 27.1: progettare per una cerniera

Il 23 ottobre 2026 il WebKit Blog ha pubblicato le novità di Safari 27.1 per iPhone Duo, un dispositivo pieghevole. Per chi sviluppa interfacce arrivano due API note nel mondo dei foldable: Device Posture e Viewport Segments. Non sono attive di default, ma mostrano come cambia il responsive design quando la forma della pagina varia mentre è aperta.

Che cosa è disponibile e in che stato

Entrambe le API sono in anteprima per sviluppatori. Si attivano da Impostazioni, App, Safari, Avanzate, Feature Flags, accendendo "Device Posture API" e "Viewport Segments API". L'articolo avverte che possono ancora cambiare e chiede feedback. Il post riguarda un solo dispositivo e non offre dati di adozione, quindi oggi non c'è nulla da dare per scontato in produzione.

Device Posture: piegato o continuo

La postura ha due valori. Con folded il dispositivo è piegato parzialmente, come un libro o un portatile. Con continuous è piatto, sia completamente aperto sia completamente chiuso. In CSS si usa la media query device-posture, in JavaScript navigator.devicePosture.type insieme all'evento change.

@media (device-posture: folded) {
  /* regole per la postura piegata */
}

function reportPosture() {
  console.log(`Device posture: ${navigator.devicePosture.type}`);
}
reportPosture();
navigator.devicePosture.addEventListener("change", reportPosture);

MDN precisa che sui dispositivi non pieghevoli il valore è sempre continuous e che gli strumenti di sviluppo dei browser possono simulare un foldable solo completamente aperto o chiuso. Per provare lo stato piegato serve quindi un dispositivo reale, oppure, come indica WebKit, il simulatore di iPhone Duo in Device Hub, incluso da Xcode 27.1 in poi.

Viewport Segments: due pannelli e una cerniera

Quando una cerniera divide lo schermo, la pagina può conoscere i segmenti. Le media query horizontal-viewport-segments e vertical-viewport-segments indicano quanti segmenti ci sono, affiancati nella posa a libro o impilati nella posa a portatile. Sei variabili env() ne descrivono le dimensioni e la posizione: viewport-segment-width, height, top, right, bottom e left. Ciascuna prende due indici, prima la colonna poi la riga, a partire da 0 in alto a sinistra.

@media (horizontal-viewport-segments: 2) {
  .wrapper {
    display: grid;
    grid-template-columns:
      env(viewport-segment-width 0 0)
      env(viewport-segment-width 1 0);
  }
}

In JavaScript, window.viewport.segments restituisce un array di DOMRect, uno per segmento, da rileggere quando cambia la postura o la finestra viene ridimensionata.

Le dimensioni da avere in mente

WebKit indica per iPhone Duo larghezze del viewport tra 382 e 951 pixel CSS e altezze tra 368 e 902. Il display esterno in verticale è largo 382 pixel, in orizzontale 594. Il display interno in verticale è largo 669, in orizzontale 951, e con due finestre affiancate ciascuna è larga 385. Il post raccomanda responsive design e feature detection, non user agent sniffing.

Un approccio prudente

La logica che propongo è mia e si basa sulle indicazioni di MDN di verificare l'esistenza delle API. Il layout di base deve funzionare su un unico viewport. I segmenti si aggiungono dopo, solo se il browser li espone.

.wrapper { display: block; }

@media (horizontal-viewport-segments: 2) {
  .wrapper {
    display: grid;
    grid-template-columns:
      env(viewport-segment-width 0 0)
      env(viewport-segment-width 1 0);
  }
}

if ("viewport" in window && navigator.devicePosture) {
  // leggi window.viewport.segments e ascolta change e resize
}

Nei browser che non conoscono la media query la regola semplicemente non si applica, e la pagina resta quella di base. Per chi progetta, la conseguenza è disegnare due stati in più, piegato e continuo, e pensare a cosa succede al contenuto quando la postura cambia con la pagina già aperta.

Quello che ancora manca

In Safari 27.1 il contenuto web non si estende sotto i controlli di sistema sul lato: Safari riempie quello spazio con il colore di sfondo della pagina. WebKit discute viewport-fit="cover" ma dice che Apple sta ancora valutando un approccio più affidabile, e non annuncia nulla di rilasciato. MDN, dal canto suo, classifica entrambe le API come sperimentali e non Baseline. La tabella di compatibilità non mi è risultata leggibile, quindi non indico quali altri browser le supportino.

Vale la pena occuparsene oggi?

Se il tuo pubblico usa pieghevoli, o se hai un prodotto con pannelli affiancati come lista e dettaglio, conviene sperimentare ora con la logica a miglioramento progressivo. Altrimenti basta sapere che esiste e tenerlo d'occhio finché le API escono dai flag.

Fonti

1. WebKit Blog, Jen Simmons, “WebKit Features for Safari 27.1”, 23 ottobre 2026
2. MDN, “Viewport Segments API”
3. MDN, “Device Posture API”