Il motivo per cui \u00e8 necessario trovare una soluzione per le \u201cimmagini responsive\u201d \u00e8 che occorre inviare immagini ottimizzate sul contesto dell’utente finale, piuttosto che dare a tutti la pi\u00f9 grande immagine potenzialmente necessaria. Sfortunatamente, tutto ci\u00f2 non \u00e8 cos\u00ec semplice nella pratica come lo \u00e8 nella teoria.<\/p>\n
Recentemente, tutte le discussioni in corso<\/a> riguardanti le immagini responsive sono diventate realt\u00e0: si sta discutendo una soluzione con il WHATWG. Attualmente, ci troviamo nel bel mezzo di questa discussione: stiamo mandando in giro riferimenti a Il pattern di markup che verr\u00e0 scelto avr\u00e0 un’enorme influenza sul modo in cui gli sviluppatori creeranno i siti web in futuro: non solo i siti web responsive o quelli adaptive, ma tutti i siti web.<\/p>\n Riesaminiamo il percorso che ci ha condotto fin qui ancora una volta, con amore:<\/p>\n La prima discussione sulle immagini responsive cominci\u00f2, \u00e8 piuttosto intuibile, all’interno del contesto del responsive web design<\/a>. Un’immagine senza bordi bianchi in un contenitore flessibile richiede un’immagine sufficientemente grande da coprire la dimensione del display pi\u00f9 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\u00e9 si adatti a un display pi\u00f9 piccolo \u00e8 un problema triviale in CSS ma richiede che la dimensione dell’immagine rimanga la stessa e, minore lo schermo maggiore la possibilit\u00e0 che la larghezza di banda sia preziosa.<\/p>\n \u00c8 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\u00f9 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.<\/p>\n Ho parlato degli sforzi iniziali nel mio articolo precedente su ALA<\/a>, cos\u00ec 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.<\/p>\n Quelli tra noi che stanno lavorando a tale questione hanno formato il Responsive Images Community Group<\/a> (RICG) per facilitare le conversazioni con chi si occupa degli standard e con i rappresentanti dei vari browser.<\/p>\n \u201cIl W3C ha creato Community Groups and Business Groups cos\u00ec che gli sviluppatori, i designer e chiunque sia appassionato di Web abbia un posto dove discutere e pubblicare i documenti.\u201d Sfortunatamente, eravamo vittime dell’impressione che Community Groups condividesse una connessione pi\u00f9 profonda inerente con chi si occupa di standard rispetto a quella che ha in realt\u00e0. Quando la scorsa settimana il WHATWG ha proposto una soluzione<\/a>, 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.<\/p>\n<\/div>\n Il pattern attualmente proposto dal WHATWG<\/a> \u00e8 il nuovo attributo La sintassi proposta \u00e8:<\/p>\n \u00a0<\/p>\n \u00a0<\/p>\n Ho dei dubbi riguardo a questa nuova sintassi, ma ci arrivo tra un attimo.<\/p>\n Il pattern di markup proposto in precedenza dal RICG (il community group di cui faccio parte) ha come scopo quello di usare la flessibilit\u00e0 propria delle media query<\/a> per determinare la risorsa pi\u00f9 appropriata per il contesto di navigazione dell’utente. Usa anche il comportamento gi\u00e0 specificato per l’utilizzo nell’elemento Tale markup si presenta cos\u00ec:<\/p>\n \u00a0<\/p>\n \u00a0<\/p>\n Attraverso Github, questo pattern \u00e8 stato codificato in quanto pi\u00f9 vicino alla specifica<\/a> riuscissi a fare, per poter cos\u00ec avere tutti i dettagli implementativi pi\u00f9 importanti in un solo posto.<\/p>\n<\/div>\n Finora, c’erano due polyfill per portare la funzionalit\u00e0 di Per quel che ne so, non c’\u00e8 nessun polyfill al momento per il nuovo pattern Fortunatamente, entrambe i pattern forniscono un fallback affidabile se la nuova funzionalit\u00e0 non \u00e8 supportata nativamente e se nessun polyfill \u00e8 stato applicato: I partecipanti del WHATWG hanno stabilito nella loro mailing list pubblica<\/a> e attraverso il loro canale IRC #WHATWG<\/a> che i rappresentanti dei browser preferiscono il pattern D’altro canto, la comunit\u00e0 dei web developer ha portato avanti con tenacia<\/a> il pattern di markup Sebbene le preferenze del WHATWG e quelle della comunit\u00e0 dei web developer siano differenti, devono sicuramente essere tenute in considerazione per finalizzare una soluzione standard al problema delle immagini responsive, la nostra pi\u00f9 grande priorit\u00e0 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.<\/p>\n Per questo motivo (per il bene di chi usa il web), \u00e8 importantissimo non far diventare questa discussione un \u201cnoi contro di voi\u201d. I rappresentanti degli standard, i rappresentanti dei browser e gli sviluppatori sono tutti partner in questo sforzo. Abbiamo tutti un obiettivo pi\u00f9 alto: rendere il web accessibile, usabile e piacevole per tutti. Sia che si preferisca Detto ci\u00f2, ho alcuni grandi problemi con la sintassi di I casi d’uso sono una lista di applicazioni potenziali dei pattern di markup, dei problemi che cercano di risolvere e dei benefici.<\/p>\n Ho pubblicato una lista di casi d’uso<\/a> per l’elemento Al momento, non \u00e8 stata pubblicata alcuna lista di casi d’uso per \u00c8 di vitale importanza avere un modo per avvantaggiarsi di nuove tecniche per determinare le capacit\u00e0 lato client da quando saranno a nostra disposizione e l’elemento Potremmo avere la stessa base anche nel tag Non mi interessa dire che il markup di Come ho detto nella mailing list WHATWG, tuttavia, data una nuova sintassi completamente sconosciuta e in qualche modo enigmatica, penso sia molto pi\u00f9 probabile che vedremo qualcosa di simile a quanto segue:<\/p>\n \u00a0<\/p>\n \u00a0<\/p>\n Diventa:<\/p>\n \u00a0<\/p>\n \u00a0<\/p>\n O:<\/p>\n \u00a0<\/p>\n \u00a0<\/p>\n Indipendentemente da quanto degradino \u201ccon grazia\u201d questi errori, credo che questo sia un gioco \u201ctrova le differenze\u201d a cui pochissimi sviluppatori non vedono l’ora di partecipare.<\/p>\n Non pretendo di essere pi\u00f9 intelligente dello sviluppatore medio, ma parlo da \u201ccore contributor\u201d a jQuery Mobile e dalle mie esperienze lavorative sul sito responsive BostonGlobe.com: creare risorse su misura per le capacit\u00e0 client \u00e8 la mia specialit\u00e0. Ad essere completamente onesto, non capisco completamente il comportamento proposto<\/a>.<\/p>\n Odio l’idea che stiamo lastricando la via per numerosi errori solo perch\u00e9 Gli autori non dovrebbero essere caricati di complessit\u00e0 ulteriore. Se verr\u00e0 implementato, Sono sicuro che nessuno difender\u00e0 fino alla morte l’idea che i tag Qualunque miglioramento all’invio delle risorse client-side dovrebbe essere applicato universalmente. Introducendo una sistema completamente eterogeneo per determinare quale risorsa dovr\u00e0 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 \u00c8 difficile immaginare perch\u00e9 ci sia stata una difesa cos\u00ec veemente del markup Sar\u00f2 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\u00e0 di sviluppatori ha messo nella soluzione dell’elemento Se avete a cuore questo argomento, incoraggio tutti voi designer e sviluppatori ad iscrivervi alla mailing list del WHATWG<\/a> e al canale IRC<\/a> per partecipare alla discussione in corso.<\/p>\n 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\u00e0 migliorato.<\/p>\n<\/div>\n","protected":false},"excerpt":{"rendered":" Un responsive design responsabile richiede delle immagini responsive: immagini le cui dimensioni e la cui grandezza del file sia giusta per la viewport e per la larghezza di banda del dispositivo che le riceve. Dal momento che HTML non fornisce alcun elemento standard per questo scopo, utilizzare immagini responsive implica l’uso di alcuni trucchi JavaScript ed accettare che la propria soluzione non andr\u00e0 bene per alcuni utenti.<\/p>\n Di conseguenza, qualche mese fa, in risposta ad una articolo qui pubblicato, si \u00e8 formato il W3C Responsive Images Community Group, che ha proposto un elemento \u201cpicture\u201d in HTML semplice da capire e capace di inviare immagini responsive. Il gruppo ha anche delineato la funzionalit\u00e0 di \u201cpicture\u201c nei browser pi\u00f9 vecchi, utilizzando due polyfill: ossia, Picturefill di Scott Jehl e jQuery Picture di Abban Dunne. Il WHATWG ha risposto ignorando il lavoro della community sull’elemento \u201cpicture\u201d e proponendo una configurazione pi\u00f9 complessa con l’elemento img set.<\/p>\n Quale dei due standard \u00e8 migliore e per chi lo \u00e8? Quale dei due vincer\u00e0? Cosa potete fare per cercare di evitare una crisi noi contro di loro che potrebbe nuocere agli utenti finali e far abbandonare il processo degli standard agli sviluppatori? Mat Marquis di ALA ci spiega i pro e i contro delle immagini responsive ed il punto di svolta degli standard web.<\/p>\n","protected":false},"author":818,"featured_media":7000659,"comment_status":"open","ping_status":"open","template":"","categories":[247,67,274,257],"tags":[],"coauthors":[352],"class_list":["post-271","article","type-article","status-publish","has-post-thumbnail","hentry","category-html","category-numero-52-28-maggio-2012","category-responsive-design","category-stato-del-web"],"jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/article\/271","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/article"}],"about":[{"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/types\/article"}],"author":[{"embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/users\/818"}],"replies":[{"embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/comments?post=271"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/media\/7000659"}],"wp:attachment":[{"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/media?parent=271"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/categories?post=271"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/tags?post=271"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/coauthors?post=271"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}picture<\/code> e image set<\/code>, facendo vaghi riferimenti ai polyfill e alludendo a degli \u201cuse cases\u201d come se gli sviluppatori sparsi per il mondo stessero seguendo tutte le missive sull’argomento. C’\u00e8 molto da vagliare, specialmente se vi state sintonizzando solo ora, durante i secondi finali della partita.<\/p>\nQuant’\u00e8 lungo, strano, etc.<\/h2>\n
\n
\u2014http:\/\/www.w3.org\/community\/<\/a><\/p>\n<\/blockquote>\nI pattern di markup proposti<\/h2>\n
set<\/code> dell’elemento img<\/code>. Quello che posso dedurre dalla descrizione<\/a> \u00e8 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\u00e0 di pixel nelle parti ‘1x’\/’2x’ della stringa.<\/p>\n<img src=\"face-600-200@1.jpg\" alt=\"\"\n set=\"face-600-200@1.jpg 600w 200h 1x,\n face-600-200@2.jpg 600w 200h 2x,\n face-icon.png 200w 200h\">\n<\/code><\/pre>\nvideo<\/a><\/code>, in mezzo agli attributi media<\/code>, cos\u00ec che il caricamento condizionale delle risorse media segua un pattern predicibile e consistente.<\/p>\n<picture alt=\"\">\n <source src=\"mobile.jpg\" \/> \n <source src=\"large.jpg\" media=\"min-width: 600px\" \/>\n <source src=\"large_1.5x-res.jpg\" media=\"min-width: 600px, \u00bb\n min-device-pixel-ratio: 1.5\" \/>\n <img src=\"mobile.jpg\" \/>\n<\/picture>\n<\/code><\/pre>\nPolyfill<\/h2>\n
picture<\/code> proposto da RICG nei vecchi browser: Picturefill<\/a> di Scott Jehl e jQuery Picture<\/a> di Abban Dunne.<\/p>\nimg set<\/code> proposto da WHATWG. \u00c8 bene notare che qualunque polyfill per qualsiasi soluzioni che si basi sul tag img<\/code> probabilmente soffrir\u00e0 degli stessi problemi<\/a> che abbiamo incontrato quando abbiamo cercato di implementare in passato una soluzione personalizzata per le \u201cimmagini responsive\u201d.<\/p>\nimg set<\/code> usa l’attributo src originale dell’immagine e picture<\/code> usa lo stesso pattern di fallback testato per il tag video<\/code>. Quando viene<\/em> 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<\/code> e un tag img<\/code> nell’esempio di picture<\/code> mostrato sopra.<\/p>\n<\/div>\nProposte differenti<\/h2>\n
img set<\/code>, che \u00e8 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.<\/p>\npicture<\/code>. Molti sviluppatori che hanno familiarit\u00e0 con questo argomento hanno stabilito senza ombra di dubbio che la sintassi di img set<\/code> \u00e8 nel migliore dei casi poco conosciuta e nel peggiore completamente indecifrabile. Non ricordo questo tipo di unit\u00e0 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.<\/p>\n<\/div>\nSiamo sulla stessa barca<\/h2>\n
img set<\/code> o picture<\/code>, sono sicuro che tutte le persone coinvolte stanno lavorando verso un obiettivo comune e siamo tutti d’accordo che l’approccio \u201cmassimo comun denominatore\u201d sia inammissibile. Semplicemente, non possiamo inviare immagini enormi e ad alta risoluzioni indiscriminatamente: il loro costo potenziale per i nostri utenti \u00e8 troppo grande, specialmente considerando le decine di migliaia di utenti nei paesi in via di sviluppo che pagano per ogni kilobyte in pi\u00f9 che consumano, ma senza avere alcun beneficio dal grande file che hanno scaricato.<\/p>\nimg set<\/code>, almeno nella sua incarnazione attuale.<\/p>\n1. Casi d’uso<\/h3>\n
picture<\/code> sul wiki del WHATWG. Questo elenco non ha pretese di essere esaustivo, dal momento che picture<\/code> pu\u00f2 inviare una risorsa immagine basandosi su una combinazione di media query. Il caso d’uso pi\u00f9 comune, sicuramente, \u00e8 quello delle dimensioni e risoluzioni dello schermo, ma potrebbe estendersi cos\u00ec 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.<\/p>\nimg set<\/code>. Abbiamo lavorato sotto l’assunzione, basata sulle conversazioni sulla lista del WHATWG e nel canale IRC di WHATWG, che img set<\/code> copre due usi specifici: inviare immagini ad alta risoluzione agli schermi ad alta risoluzione e funzionalit\u00e0 simile alla media query min-width<\/code> nella maniera della stringa 600w<\/code>.<\/p>\npicture<\/code> ci d\u00e0 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.<\/p>\nimg<\/code>, ma in una maniera inevitabilmente frammentata.<\/p>\n2. Margine d’errore<\/h3>\n
img set<\/code> \u00e8 imperscrutabile. \u00c8 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\u00e0 inevitabilmente ad errori nella scrittura. In questa situazione a rimetterci saranno gli utenti finali.<\/p>\n\n<img src=\"face-600-200@1.jpeg\" alt=\"\"\n set=\"face-600-200@1.jpeg 600w 1x,\n face-600-200@2.jpeg 600w 2x,\n face-icon.png 200w\">\n<\/code><\/pre>\n\n<img src=\"face-600-200@1.jpeg\" alt=\"\"\n set=\"face-600-200@1.jpeg 600 1x,\n face-600-200@2.jpeg 600 2x,\n face-icon.png 200\">\n<\/code><\/pre>\n\n<img src=\"face-600-200@1.jpeg\" alt=\"\"\n set=\"face-600-200@1.jpeg, 600w 1x\n face-600-200@2.jpeg 600w 2x,\n face-icon.png 200w\">\n<\/code><\/pre>\nimg set<\/code> \u00e8 pi\u00f9 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<\/a> 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<\/a>, supportare il contenuto esistente ed evitare la complessit\u00e0 inutile.<\/p>\n<\/div>\nEvitare la complessit\u00e0 inutile<\/h2>\n
img set<\/code> introdurr\u00e0 innumerevoli punti di fallimento e, alla peggio, qualcosa di cos\u00ec indecifrabile che gli autori eviteranno semplicemente di usarlo.<\/p>\nvideo<\/code> e audio<\/code> siano termini di paragone di markup efficiente, ma funzionano<\/em>. In ogni caso, i precedenti che hanno creato dureranno. Asfaltare i sentieri.<\/em> Questo \u00e8 il modo in cui HTML5 gestisce i rich media con risorse condizionali e gli autori hanno gi\u00e0 familiarit\u00e0 con questi pattern di markup. I costi potenziali di scarto superano di gran lunga i benefici immediati degli implementatori.<\/p>\nmedia<\/code> utilizzato dai tag video<\/code> e una volta per il tag img<\/code> 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<\/em> degli standard web, non il nuovo e razionale mondo che gli standard dovrebbero supportare.<\/p>\n<\/div>\nLa logica che non osa dire il suo nome<\/h2>\n
img set<\/code>. L’elemento picture<\/code> fornisce un numero maggiore di potenziali casi d’uso, ha due polyfill funzionali gi\u00e0 oggi (mentre potrebbe non essere nemmeno possibile<\/a> un polyfill efficiente con il pattern img set<\/code>) e ha visto un supporto senza precedenti da parte della comunit\u00e0 degli sviluppatori.<\/p>\nimg set<\/code> \u00e8 il pattern preferito dagli implementatori di browser e, sebbene sia sicuramente un fattore chiave, non giustifica una soluzione insufficiente. La mia preoccupazione \u00e8 che l’argomento non detto contro picture<\/code> sulla mailing list di WHATWG \u00e8 che non l’hanno inventato loro<\/a>. La mia paura<\/em> \u00e8 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).<\/p>\nNoi, le persone che creano siti web<\/h3>\n
picture<\/code> \u00e8 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.<\/p>\n