Le immagini responsive e gli standard Web a un punto di svolta

Quant’è lungo, strano, etc.#section1

Riesaminiamo il percorso che ci ha condotto fin qui ancora una volta, con amore:

La prima discussione sulle immagini responsive cominciò, è piuttosto intuibile, all’interno del contesto del responsive web design. Un’immagine senza bordi bianchi in un contenitore flessibile richiede un’immagine sufficientemente grande da coprire la dimensione del display più grande possibile. Un’immagine progettata per espandersi in un contenitore largo al massimo duemila pixel implica l’invio di un’immagine di almeno duemila pixel di larghezza. Scalare quell’immagine perché si adatti a un display più piccolo è un problema triviale in CSS ma richiede che la dimensione dell’immagine rimanga la stessa e, minore lo schermo maggiore la possibilità che la larghezza di banda sia preziosa.

È chiaro che i migliori sforzi degli sviluppatori per mitigare queste richieste dispendiose fossero tutte destinate a non essere all’altezza e non per la mancanza di talenti o di sforzi: alcune delle menti più brillanti del mobile web e del web development in generale si erano davvero riunite con l’intento di risolvere questo problema. Per qualche ragione, c’ero anch’io.

Ho parlato degli sforzi iniziali nel mio articolo precedente su ALA, così vi risparmio i raccapriccianti dettagli qui. In sostanza, non possiamo aprirci un varco in questa situazione. Il problema rimane tuttavia chiaro e deve essere risolto, ma non possiamo farlo con le tecnologie che abbiamo adesso a nostra disposizione. Ci serve qualcosa di nuovo.

Quelli tra noi che stanno lavorando a tale questione hanno formato il Responsive Images Community Group (RICG) per facilitare le conversazioni con chi si occupa degli standard e con i rappresentanti dei vari browser.

“Il W3C ha creato Community Groups and Business Groups così che gli sviluppatori, i designer e chiunque sia appassionato di Web abbia un posto dove discutere e pubblicare i documenti.”
—http://www.w3.org/community/

Sfortunatamente, eravamo vittime dell’impressione che Community Groups condividesse una connessione più profonda inerente con chi si occupa di standard rispetto a quella che ha in realtà. Quando la scorsa settimana il WHATWG ha proposto una soluzione, molte persone coinvolte in quella discussione non avevano partecipato al RICG. In effetti, alcune persone incaricate di prendere delle decisioni importanti non ne avevano praticamente mai sentito parlare.

I pattern di markup proposti#section2

Il pattern attualmente proposto dal WHATWG è il nuovo attributo set dell’elemento img. Quello che posso dedurre dalla descrizione è che questo markup ha lo scopo di risolvere due questioni molto specifiche: un equivalente della media query ‘min-width’ nelle parti ‘600w 200h’ della stringa e la densità di pixel nelle parti ‘1x’/’2x’ della stringa.

La sintassi proposta è:

<img src="face-600-200@1.jpg" alt=""
    set="face-600-200@1.jpg 600w 200h 1x,
         face-600-200@2.jpg 600w 200h 2x,
         face-icon.png      200w 200h">

Ho dei dubbi riguardo a questa nuova sintassi, ma ci arrivo tra un attimo.

Il pattern di markup proposto in precedenza dal RICG (il community group di cui faccio parte) ha come scopo quello di usare la flessibilità propria delle media query per determinare la risorsa più appropriata per il contesto di navigazione dell’utente. Usa anche il comportamento già specificato per l’utilizzo nell’elemento video, in mezzo agli attributi media, così che il caricamento condizionale delle risorse media segua un pattern predicibile e consistente.

Tale markup si presenta così:

<picture alt="">
   <source src="mobile.jpg" /> 
   <source src="large.jpg" media="min-width: 600px" />
   <source src="large_1.5x-res.jpg" media="min-width: 600px, »
       min-device-pixel-ratio: 1.5" />
   <img src="mobile.jpg" />
</picture>

Attraverso Github, questo pattern è stato codificato in quanto più vicino alla specifica riuscissi a fare, per poter così avere tutti i dettagli implementativi più importanti in un solo posto.

Polyfill#section3

Finora, c’erano due polyfill per portare la funzionalità di picture proposto da RICG nei vecchi browser: Picturefill di Scott Jehl e jQuery Picture di Abban Dunne.

Per quel che ne so, non c’è nessun polyfill al momento per il nuovo pattern img set proposto da WHATWG. È bene notare che qualunque polyfill per qualsiasi soluzioni che si basi sul tag img probabilmente soffrirà degli stessi problemi che abbiamo incontrato quando abbiamo cercato di implementare in passato una soluzione personalizzata per le “immagini responsive”.

Fortunatamente, entrambe i pattern forniscono un fallback affidabile se la nuova funzionalità non è supportata nativamente e se nessun polyfill è stato applicato: img set usa l’attributo src originale dell’immagine e picture usa lo stesso pattern di fallback testato per il tag video. Quando viene riconosciuto il nuovo elemento, il contenuto di fallback fornito all’interno dell’elemento viene ignorato: ad esempio, un video in Flash nel caso del tag video e un tag img nell’esempio di picture mostrato sopra.

Proposte differenti#section4

I partecipanti del WHATWG hanno stabilito nella loro mailing list pubblica e attraverso il loro canale IRC #WHATWG che i rappresentanti dei browser preferiscono il pattern img set, che è una considerazione importante durante queste conversazioni. La maggior parte dei membri del WHATWG sono rappresentanti dei browser principali quindi comprendono il mondo dei browser meglio di chiunque altro.

D’altro canto, la comunità dei web developer ha portato avanti con tenacia il pattern di markup picture. Molti sviluppatori che hanno familiarità con questo argomento hanno stabilito senza ombra di dubbio che la sintassi di img set è nel migliore dei casi poco conosciuta e nel peggiore completamente indecifrabile. Non ricordo questo tipo di unità tra i membri di una community riguardo una qualsiasi discussione sugli standard web nel passato e nemmeno in alcuna conversazione riguardante la semantica del markup.

Siamo sulla stessa barca#section5

Sebbene le preferenze del WHATWG e quelle della comunità dei web developer siano differenti, devono sicuramente essere tenute in considerazione per finalizzare una soluzione standard al problema delle immagini responsive, la nostra più grande priorità deve rimanere quella di fornire un chiaro beneficio agli utenti: i bisogni dell’utente vincono sulla convenienza dei web developer e degli sviluppatori di browser.

Per questo motivo (per il bene di chi usa il web), è importantissimo non far diventare questa discussione un “noi contro di voi”. I rappresentanti degli standard, i rappresentanti dei browser e gli sviluppatori sono tutti partner in questo sforzo. Abbiamo tutti un obiettivo più alto: rendere il web accessibile, usabile e piacevole per tutti. Sia che si preferisca img set o picture, sono sicuro che tutte le persone coinvolte stanno lavorando verso un obiettivo comune e siamo tutti d’accordo che l’approccio “massimo comun denominatore” sia inammissibile. Semplicemente, non possiamo inviare immagini enormi e ad alta risoluzioni indiscriminatamente: il loro costo potenziale per i nostri utenti è troppo grande, specialmente considerando le decine di migliaia di utenti nei paesi in via di sviluppo che pagano per ogni kilobyte in più che consumano, ma senza avere alcun beneficio dal grande file che hanno scaricato.

Detto ciò, ho alcuni grandi problemi con la sintassi di img set, almeno nella sua incarnazione attuale.

1. Casi d’uso#section6

I casi d’uso sono una lista di applicazioni potenziali dei pattern di markup, dei problemi che cercano di risolvere e dei benefici.

Ho pubblicato una lista di casi d’uso per l’elemento picture sul wiki del WHATWG. Questo elenco non ha pretese di essere esaustivo, dal momento che picture può inviare una risorsa immagine basandosi su una combinazione di media query. Il caso d’uso più comune, sicuramente, è quello delle dimensioni e risoluzioni dello schermo, ma potrebbe estendersi così tanto da inviare una “source” per l’immagine appropriata al layout per visualizzarla sullo schermo e una versione ad alta risoluzione per la stampa, tutte sulla stessa pagina, senza bisogno di script aggiuntivi.

Al momento, non è stata pubblicata alcuna lista di casi d’uso per img set. Abbiamo lavorato sotto l’assunzione, basata sulle conversazioni sulla lista del WHATWG e nel canale IRC di WHATWG, che img set copre due usi specifici: inviare immagini ad alta risoluzione agli schermi ad alta risoluzione e funzionalità simile alla media query min-width nella maniera della stringa 600w.

È di vitale importanza avere un modo per avvantaggiarsi di nuove tecniche per determinare le capacità lato client da quando saranno a nostra disposizione e l’elemento picture ci dà una base solida su cui costruire, man mano che le media query si evolveranno nel tempo, potremmo trovare infiniti modi per inviare una risorsa in maniera personalizzata.

Potremmo avere la stessa base anche nel tag img, ma in una maniera inevitabilmente frammentata.

2. Margine d’errore#section7

Non mi interessa dire che il markup di img set è imperscrutabile. È un pattern di markup diverso da qualunque cosa si sia vista prima in HTML o CSS. Questo va ben oltre le preferenze dell’autore: una sintassi non familiare condurrà inevitabilmente ad errori nella scrittura. In questa situazione a rimetterci saranno gli utenti finali.

Come ho detto nella mailing list WHATWG, tuttavia, data una nuova sintassi completamente sconosciuta e in qualche modo enigmatica, penso sia molto più probabile che vedremo qualcosa di simile a quanto segue:

<img src="face-600-200@1.jpeg" alt=""
       set="face-600-200@1.jpeg 600w 1x,
           face-600-200@2.jpeg  600w 2x,
           face-icon.png        200w">

Diventa:

<img src="face-600-200@1.jpeg" alt=""
      set="face-600-200@1.jpeg 600 1x,
           face-600-200@2.jpeg 600 2x,
           face-icon.png       200">

O:

<img src="face-600-200@1.jpeg" alt=""
      set="face-600-200@1.jpeg, 600w 1x
           face-600-200@2.jpeg  600w 2x,
           face-icon.png        200w">

Indipendentemente da quanto degradino “con grazia” questi errori, credo che questo sia un gioco “trova le differenze” a cui pochissimi sviluppatori non vedono l’ora di partecipare.

Non pretendo di essere più intelligente dello sviluppatore medio, ma parlo da “core contributor” a jQuery Mobile e dalle mie esperienze lavorative sul sito responsive BostonGlobe.com: creare risorse su misura per le capacità client è la mia specialità. Ad essere completamente onesto, non capisco completamente il comportamento proposto.

Odio l’idea che stiamo lastricando la via per numerosi errori solo perché img set è più semplice da implementare nei browser. L’implementazione a lato browser avviene una sola volta, mentre la scrittura di codice avviene migliaia di volte e, in accordo con i principi di design di HTML5 stessi, i bisogni degli autori devono avere precedenza sui bisogni dei creatori di browser. Per non menzionare questi altri principi di HTML5: risolvere problemi reali, asfaltare i sentieri, supportare il contenuto esistente ed evitare la complessità inutile.

Evitare la complessità inutile#section8

Gli autori non dovrebbero essere caricati di complessità ulteriore. Se verrà implementato, img set introdurrà innumerevoli punti di fallimento e, alla peggio, qualcosa di così indecifrabile che gli autori eviteranno semplicemente di usarlo.

Sono sicuro che nessuno difenderà fino alla morte l’idea che i tag video e audio siano termini di paragone di markup efficiente, ma funzionano. In ogni caso, i precedenti che hanno creato dureranno. Asfaltare i sentieri. Questo è il modo in cui HTML5 gestisce i rich media con risorse condizionali e gli autori hanno già familiarità con questi pattern di markup. I costi potenziali di scarto superano di gran lunga i benefici immediati degli implementatori.

Qualunque miglioramento all’invio delle risorse client-side dovrebbe essere applicato universalmente. Introducendo una sistema completamente eterogeneo per determinare quale risorsa dovrà essere inviata al client, i miglioramenti potrebbero anche dover essere fatti in due volte per andare bene in due sistemi: una volta per l’attributo media utilizzato dai tag video e una volta per il tag img da solo. Questo potrebbe significare avere due basi di codice (che in effetti hanno lo stesso scopo) da mantenere da parte degli implementatori, mentre gli autori dovrebbero imparare due diversi metodi per ogni avanzamento fatto. Sembra il mondo prima degli standard web, non il nuovo e razionale mondo che gli standard dovrebbero supportare.

La logica che non osa dire il suo nome#section9

È difficile immaginare perché ci sia stata una difesa così veemente del markup img set. L’elemento picture fornisce un numero maggiore di potenziali casi d’uso, ha due polyfill funzionali già oggi (mentre potrebbe non essere nemmeno possibile un polyfill efficiente con il pattern img set) e ha visto un supporto senza precedenti da parte della comunità degli sviluppatori.

img set è il pattern preferito dagli implementatori di browser e, sebbene sia sicuramente un fattore chiave, non giustifica una soluzione insufficiente. La mia preoccupazione è che l’argomento non detto contro picture sulla mailing list di WHATWG è che non l’hanno inventato loro. La mia paura è che le conseguenze di questa filosofia radicata potrebbe ricadere sugli utenti. Sono loro a soffrire quando i nostri siti falliscono (o quando gli sviluppatori, incapaci di comprendere la sintassi complessa del WHATWG, semplicemente forzano tutti gli utenti a scaricare dei file immagine enormi).

Noi, le persone che creano siti web#section10

Sarò onesto: per me, nessuna minima parte di questo riguarda l’essere sicuri che noi designer e sviluppatori possiamo avere una voce nel processo degli standard. Lo sforzo che la comunità di sviluppatori ha messo nella soluzione dell’elemento picture è senza precedenti e posso solo sperare che segni l’inizio di una lunga e reciprocamente benefica relazione tra noi autori e le associazioni di standard, per quanto tumultuoso possa essere questo inizio.

Se avete a cuore questo argomento, incoraggio tutti voi designer e sviluppatori ad iscrivervi alla mailing list del WHATWG e al canale IRC per partecipare alla discussione in corso.

Noi sviluppatori dovremmo (e potremmo) essere partner nella creazione di nuovi standard. Prestate la vostra voce a questa discussione e ad altre simili in futuro. Il web ne uscirà migliorato.