Autore

Mat Marquis

Mat Marquis twitta copiosamente, crea siti web in Bocoup per vivere e presiede il Responsive Issues Community Group. È anche technical editor di A List Apart ed è stato membro del team jQuery Mobile.

Altro di questo autore

JavaScript per Web Designers: DOM scripting

È innegabile l'abilità di JavaScript nell'accedere a e nel modificare gli elementi sulla pagina e il Document Object Model è un componente essenziale di tutto questo. In questo estratto dal nuovo libro di Mat Marquis, JavaScript for Web Designers, Mat ci mostra in che modo manovrare il DOM per ottenere risultati migliori dai nostri script.

Container Queries: uniamo le forze un’altra volta!

Le media queries sono state lo strumento da usare per creare siti responsive, permettendoci di ridimensionare e ricombinare i moduli per adattarli ai vari contesti, layout e viewport. Ma fare affidamento sulle dimensioni fisse della viewport può rapidamente far diventare i fogli di stile dei nodi gordiani. Abbiamo ancora bisogno di un modo future-friendly per gestire i CSS responsive. Mat Marquis esplora il problema e si muove verso la soluzione e ci chiama a raccolta.

A List Together

A List Apart ritorna alle sue radici: creare una community, dare una piattaforma alle nuove voci e riportare l'entusiasmo per il web tra le persone. Stiamo operando dei cambiamenti al modo in cui lavoriamo, partendo dalla nostra decisione di mettere come open source il codice stesso che fa girare alistapart.com e vorremmo che voi partecipaste. Il nostro Mat Marquis vi invita a contribuire con del codice e con delle idee via GitHub, vi presenta i nostri acquisition scout e vi sprona ad usare ALA e i suoi editor per condividere le vostre idee e i vostri insight con l'intera community del web design e development.

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

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à bene per alcuni utenti. Di conseguenza, qualche mese fa, in risposta ad una articolo qui pubblicato, si è formato il W3C Responsive Images Community Group, che ha proposto un elemento “picture” in HTML semplice da capire e capace di inviare immagini responsive. Il gruppo ha anche delineato la funzionalità di “picture“ nei browser più 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 “picture” e proponendo una configurazione più complessa con l'elemento img set. Quale dei due standard è migliore e per chi lo è? Quale dei due vincerà? 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.

Immagini responsive: perché hanno quasi funzionato e cosa ci serve

Con un approccio mobile-first responsive design, se una qualunque parte si rompe, i vostri utenti potranno ancora ricevere un'immagine rappresentativa ed evitare un'inutilmente grande richiesta su un device che potrebbe avere una banda limitata. Tuttavia con l'implementazione da parte di molti dei browser più recenti di una feature di prefetch delle immagini che permette alle immagini di essere prese prima di fare il parsing del body del documento, molti tra i più illuminati web developer stanno abbandonando le immagini responsive in favore dello user agent detection, almeno come soluzione temporanea. Per noi standardisti, l'UA detection ci lascia un cattivo sapore in bocca. Soprattutto, l'UA detection diventerà ben presto insostenibile con il crescere continuo del numero di dispositivi, esattamente come avvenne con il browser detection negli anni bui precedenti agli standard web. Quello di cui abbiamo veramente bisogno, sostiene Mat Marquis, è un nuovo elemento di markup che funzioni nel modo in cui funziona l'elemento video di HTML5. Sembra folle? Così tanto che potrebbe funzionare!