iOS 8 ha rimosso la proprietà viewport “minimal-ui”, ci sono altre soluzioni “soft fullscreen”?

(Questa è una domanda in più parti, farò del mio meglio per riassumere lo scenario).

Attualmente stiamo sviluppando un’applicazione web retriggers (lettore di notizie) che consente agli utenti di scorrere tra i contenuti a tabs, nonché di scorrere verticalmente all’interno di ogni contenuto di tabs.

Un approccio comune al problema consiste nell’avere un div wrapper che riempie la finestra del browser, impostare l’ overflow su hidden o auto , quindi scorrere orizzontalmente e / o verticalmente al suo interno.

Questo approccio è ottimo ma presenta uno svantaggio principale: poiché l’altezza del documento è esattamente la stessa della finestra del browser, il browser mobile non nasconde la barra degli indirizzi / il menu di navigazione .

Esistono numerosi hack e proprietà di viewport che ci consentono di ottenere più spazio sullo schermo, ma nessuno è altrettanto efficace di minimal-ui (introdotto in iOS 7.1).

La notizia è arrivata ieri che iOS 8 beta4 aveva rimosso minimal-ui da Mobile Safari (vedi la sezione Webkit nelle note di rilascio di iOS 8 ), cosa che ci ha fatto pensare:

Q1. È ancora ansible hide la barra degli indirizzi su Mobile Safari?

Per quanto ne sappiamo, iOS 7 non risponde più al window.scrollTo hack, questo suggerisce che dobbiamo convivere con lo spazio dello schermo più piccolo, a meno che non adottiamo un layout verticale o utilizziamo mobile-web-app-capable .

Q2. È ancora ansible avere un’esperienza simile a schermo intero soft?

Con lo schermo intero soft intendo davvero senza utilizzare il meta tag mobile-web-app-capable .

La nostra app Web è progettata per essere accessibile, qualsiasi pagina può essere aggiunta ai segnalibri o condivisa utilizzando il menu del browser nativo. Aggiungendo la funzione mobile-web-app-capable agli utenti di richiamare tale menu (quando viene salvato su homescreen), che confonde e antagonizza gli utenti.

minimal-ui era il middle-ground, nascondendo il menu di default ma mantenendolo accessibile con un touch , anche se Apple potrebbe averlo rimosso a causa di altri problemi di accessibilità (come gli utenti che non sanno dove toccare per triggersre il menu) .

Q3. Un’esperienza a schermo intero vale la pena?

Sembrerebbe che un’API a schermo intero non venga presto a iOS, ma anche se lo fosse, non vedo come il menu sarà tenuto accessibile (lo stesso vale per Chrome su Android).

In questo caso, forse dovremmo lasciare mobile safari così com’è e tenere conto dell’altezza del viewport (per iPhone 5+, è 460 = 568 – 108, dove 108 include la barra OS, la barra degli indirizzi e il menu di navigazione; per iPhone 4 o più vecchio, è 372).

Mi piacerebbe sentire alcune alternative (oltre a build un’applicazione nativa).

La proprietà viewport minimo-ui non è più supportata in iOS 8. Tuttavia, lo stesso minimal-ui non è sparito. L’utente può inserire il minimo-ui con un gesto di “trascinamento verso il basso”.

Esistono diverse pre-condizioni e ostacoli per gestire lo stato di visualizzazione, ad esempio per il minimo funzionamento di ui, ci deve essere abbastanza contenuto per consentire all’utente di scorrere; per il minimo-ui persiste, lo scorrimento della finestra deve essere sfalsato al caricamento della pagina e dopo il cambio di orientamento. Tuttavia, non c’è modo di calcolare le dimensioni del minimo-ui usando la variabile screen , e quindi nessun modo di dire quando l’utente è in anticipo con il minimo.

Queste osservazioni sono il risultato di una ricerca nell’ambito dello sviluppo di Brim – view manager per iOS 8 . L’implementazione di fine funziona nel modo seguente:

Quando la pagina è caricata, Brim creerà un elemento tapis roulant. L’elemento Treadmill è usato per dare spazio all’utente per scorrere. La presenza dell’elemento tapis roulant assicura che l’utente possa accedere alla vista minima-ui e che continui a persistere se l’utente ricarica la pagina o cambia l’orientamento del dispositivo. È invisibile all’utente per tutto il tempo. Questo elemento ha il brim-treadmill ID.

Al caricamento della pagina o dopo aver cambiato l’orientamento, Brim sta usando Scream per rilevare se la pagina è nella vista minima-ui (la pagina che è stata precedentemente in minimal-ui e che è stata ricaricata rimarrà nel minimo-ui se l’altezza del contenuto è maggiore dell’altezza del viewport).

Quando la pagina è in minime ui, Brim disabiliterà lo scorrimento del documento (lo fa in un modo sicuro che non influisce sul contenuto dell’elemento principale). La distriggerszione dello scorrimento del documento impedisce di lasciare accidentalmente l’interfaccia minima quando si scorre verso l’alto. Come per la specifica iOS 7.1 originale, toccando la barra in alto si riporta indietro il resto del chrome.

Il risultato finale assomiglia a questo:

Brim in simulatore iOS.

Per motivi di documentazione, e nel caso in cui si preferisca scrivere la propria implementazione, vale la pena notare che non è ansible utilizzare Scream per rilevare se il dispositivo si trova in un intervallo minimo dopo l’evento orientationchange perché le dimensioni della window non riflettono il nuovo orientamento fino l’animazione di rotazione è terminata. Devi colbind un listener all’evento orientationchangeend .

Scream e orientationchangeend sono stati sviluppati come parte di questo progetto.

Dal momento che non esiste un modo programmatico per imitare minimal-ui , abbiamo messo a punto una soluzione alternativa, utilizzando calc() e nota l’altezza della barra degli indirizzi iOS a nostro vantaggio:

La seguente pagina dimostrativa ( disponibile anche su gist, più dettagli tecnici lì ) chiederà all’utente di scorrere, che quindi triggers uno schermo intero soft (nascondi barra degli indirizzi / menu), dove intestazione e contenuto riempiono la nuova finestra.

      Scroll Test     

header

content

scroll to soft fullscreen

Dì solo addio a minimal-ui (per ora)

È vero, minimal-ui potrebbe essere sia utile che dannoso, e suppongo che il trade-off ora abbia un altro equilibrio, a favore di iPhone nuovi e più grandi.

Ho avuto a che fare con il problema mentre lavoravo con il mio framework js per le app HTML5. Dopo aver tentato molte soluzioni, ognuna con i loro svantaggi, mi sono arresa a considerare lo spazio perso su iPhone precedenti a 6. Data la situazione, penso che l’unico comportamento solido e prevedibile sia quello predeterminato.

In breve, ho finito per impedire qualsiasi forma di minimal-ui , quindi almeno l’altezza dello schermo è sempre la stessa e tu sai sempre quale spazio reale hai per la tua app.

Con l’aiuto del tempo, un numero sufficiente di utenti avrà più spazio.


MODIFICARE

Come lo faccio

Questo è un po ‘semplificato, per scopi dimostrativi, ma dovrebbe funzionare per te. Supponendo che tu abbia un contenitore principale

 html, body, #main { height: 100%; width: 100%; overflow: hidden; } .view { width: 100%; height: 100%; overflow: scroll; } 

Poi:

  1. quindi con js, ho impostato l’altezza di #main all’altezza disponibile della finestra. Questo aiuta anche a gestire altri bug di scorrimento presenti sia su iOS che su Android. Significa anche che devi occuparti di come aggiornarlo, basta notare che;

  2. Blocco lo scorrimento eccessivo quando si raggiungono i confini della pergamena. Questo è un po ‘più profondo nel mio codice, ma penso che si possa anche seguire il principio di questa risposta per le funzionalità di base. Penso che potrebbe flickr un po ‘, ma farà il lavoro.


Guarda la demo (su un iPhone)

Come sidenote: anche questa app è bookmarkable, poiché usa un routing interno per gli indirizzi hash, ma ho anche aggiunto un prompt agli utenti iOS da aggiungere a casa. Credo che in questo modo aiuti la lealtà e il ritorno dei visitatori (e così lo spazio perso è tornato).

Il modo più semplice che ho trovato per risolvere questo problema era impostare l’altezza degli elementi body e html al 100.1% per qualsiasi richiesta in cui l’user agent era un iphone. Funziona solo in modalità orizzontale, ma questo è tutto ciò di cui avevo bisogno.

 html.iphone, html.iphone body { height: 100.1%; } 

Dai un’occhiata a https://www.360jungle.com/virtual-tour/25

Il problema di root qui sembra che iOS8 safari non nasconderà la barra degli indirizzi quando si scorre verso il basso se il contenuto è uguale o inferiore al viewport.

Come hai già scoperto, l’aggiunta di alcune imbottiture nella parte inferiore risolve questo problema:

 html { /* enough space to scroll up to get fullscreen on iOS8 */ padding-bottom: 80px; } 
 // sort of emulate safari's "bounce back to top" scroll window.addEventListener('scroll', function(ev) { // avoids scrolling when the focused element is eg an input if ( !document.activeElement || document.activeElement === document.body ) { document.body.scrollIntoViewIfNeeded(true); } }); 

Il css sopra dovrebbe essere applicato in modo condizionale, ad esempio con UA ​​sniffing aggiungendo una class gt-ios8 a .

Voglio commentare / parzialmente rispondere / condividere i miei pensieri. Sto usando la tecnica di overflow-y: scroll per un mio grande progetto imminente. Usarlo ha due vantaggi principali.

a) Puoi usare un cassetto con pulsanti di azione dalla parte inferiore dello schermo; se il documento scorre e la barra inferiore scompare, toccando un pulsante situato nella parte inferiore dello schermo, apparirà prima la barra inferiore, quindi sarà selezionabile. Inoltre, il modo in cui questa cosa funziona, crea problemi con le modali che hanno pulsanti in fondo.

b) Quando si utilizza un elemento overflow, le uniche cose che vengono ridipinte in caso di modifiche css importanti sono quelle nella schermata visualizzabile. Questo mi ha dato un enorme incremento delle prestazioni quando si utilizza javascript per alterare css di più elementi al volo. Ad esempio, se si dispone di un elenco di 20 elementi che è necessario ridipingere e solo due di essi sono visualizzati sullo schermo nell’elemento di sorvolo, solo quelli vengono ridipinti mentre il resto viene ridisegnato durante lo scorrimento. Senza di essa tutti i 20 elementi sono ridipinti.

.. ovviamente dipende dal progetto e se hai bisogno di una delle funzionalità che ho citato. Google utilizza gli elementi overflown per gmail per utilizzare la funzionalità descritta in a). Imo, ne vale la pena, anche considerando la piccola altezza nei vecchi iPhone (372 pixel come hai detto tu).

Ho trovato questa soluzione da @doublesharp e ha funzionato perfettamente per me, quindi ho pensato di condividerlo qui:

 // track width, set to window width var width = $(window).width(); // fire on window resize $(window).resize(function() { // do nothing if the width is the same if ($(window).width()==width) return; // ... your code }); 

Quindi, per qualcosa come la barra degli indirizzi di iOS 8, quando si scorre verso il basso, il ridimensionamento della barra degli indirizzi non triggers il codice $ (finestra) .resize ().

Non ho fatto il web design per iOS ma da quello che ricordo di aver visto nelle sessioni WWDC e nella documentazione, la barra di ricerca in Mobile Safari e le barre di navigazione su tutto il sistema operativo ora verranno automaticamente ridimensionate e ridotte per mostrare più contenuti.

Puoi testarlo su Safari su un iPhone e notare che, quando scorri verso il basso per vedere più contenuti su una pagina, la barra di navigazione / ricerca viene nascosta automaticamente.

Forse lasciare la barra degli indirizzi / la barra di navigazione così com’è e non creare un’esperienza a schermo intero è ciò che è meglio. Non vedo Apple farlo presto. E al massimo non controllano automaticamente quando la barra degli indirizzi mostra / nasconde.

Certo, stai perdendo lo spazio sullo schermo, specialmente su un iPhone 4 o 4S, ma non sembra essere un’alternativa a partire dalla Beta 4.