Ti diamo il benvenuto nella seconda edizione di Chrome Dev Insider, dove condividiamo aggiornamenti sulle novità e sulle cose più interessanti della community e di Chrome. Questo è un nuovo episodio di storie interne su come affrontiamo il nostro lavoro e un rapido sguardo ad alcuni degli aggiornamenti più importanti a cui dovresti prestare attenzione.
Mi chiamo Rachel Andrew e sono la responsabile dei contenuti di web.dev e developer.chrome.com, nell'ambito del team di Developer Relations di Chrome. Lavoro sul web da oltre vent'anni, con particolare attenzione agli standard web aperti e ai CSS, e faccio parte del CSS Working Group.
Due mesi fa si è conclusa la conferenza Google I/O, durante la quale abbiamo condiviso alcuni degli aggiornamenti più importanti su come supportiamo gli sviluppatori nel rendere il web più veloce e potente, mantenendo al contempo le informazioni degli utenti sicure e private.
Una delle cose che si sono distinte (e siamo felici che la community se ne sia accorta!) è l'enorme quantità di lavoro che il team sta svolgendo per supportare più funzionalità CSS e UI sul web. In questa edizione di Chrome Dev Insider, ti mostreremo chi c'è dietro questo lavoro, come ci impegniamo a supportare gli sviluppatori di CSS e UI e cosa ci aspetta. Per questo motivo, sono entusiasta di presentare questa edizione di Insider.
Nelle notizie
Nel primo Chrome Dev Insider, abbiamo condiviso alcuni aggiornamenti sulle iniziative Compat 2021 e Interop 2022, in cui i fornitori di browser e gli attori dell'ecosistema hanno collaborato per portare sul web più funzionalità supportate da tutti i browser. L'iniziativa si concentra molto sui CSS perché l'incompatibilità del browser è una delle maggiori sfide per gli sviluppatori CSS.
Anche se per molti non si tratta di una novità, è entusiasmante vedere i progressi che abbiamo già compiuto nei vari browser.
All'inizio del mese scorso, abbiamo visto Safari annunciare una release eccezionale con Safari 16.0 Beta, che include funzionalità interessanti come query sui contenitori, sottogriglia e uno strumento di ispezione flexbox. Le versioni recenti di Firefox e Chrome includono una serie di funzionalità e correzioni interessanti. Ogni mese, nella mia serie di post Novità della piattaforma web, tratto gli aspetti chiave dei browser stabili e beta.
Notizie esclusive: supporto per sviluppatori CSS e UI
Il 2022 si è rivelato un anno entusiasmante per le funzionalità CSS, quindi abbiamo pensato che fosse il momento giusto per portarti dietro le quinte. Ho incontrato Una Kravets, responsabile delle relazioni con gli sviluppatori per l'interfaccia utente web e gli strumenti di sviluppo, e Nicole Sullivan, Product Manager per l'interfaccia utente web che si occupa di API CSS e HTML, per parlare del percorso di Chrome per supportare gli sviluppatori di interfacce utente.
Iniziamo da voi due. Raccontateci qualcosa di più su di voi.
Nicole: sono la product manager per la UI web su Chrome. Mi concentro in particolare sulle nuove API CSS e HTML e sugli sviluppatori e designer che creano UI. È un settore entusiasmante con alcune API molto importanti in arrivo, come Container Queries, Scope e (si spera) vertical rhythm.
Una: sono a capo dei team DevRel di DevTools e dell'interfaccia utente web. Ci concentriamo sul supporto degli ingegneri UI sulla piattaforma web e ci assicuriamo che abbiano gli strumenti necessari per avere successo. Sono incluse le API CSS e i componenti HTML, nonché le funzionalità di DevTools per visualizzare le modifiche attive e il feedback.
Il supporto di Chrome per gli sviluppatori di UI ha subito un'accelerazione negli ultimi anni. Perché pensi che ci abbiamo messo così tanto tempo ad arrivare qui? Quali sono state le sfide più grandi?
Una: dovevamo dimostrare l'importanza di questo lavoro e perché dovesse essere una priorità. Abbiamo iniziato con il sondaggio MDN DNA nel 2019, che ha identificato l'interfaccia utente come uno dei principali punti deboli della piattaforma. Da allora, abbiamo continuato a utilizzare i dati come guida attraverso MDN e i nostri sondaggi interni sulla soddisfazione degli sviluppatori. Il risultato di tutto ciò è che siamo riusciti a ottenere un maggiore coinvolgimento della leadership e a dare la priorità al lavoro di ingegneria su alcune delle funzionalità per sviluppatori più richieste nello spazio dell'interfaccia utente, che costituiscono anche la maggior parte dell'attenzione per iniziative come Compat 2021 e Interop 2022.
Nicole: oltre a ottenere l'approvazione della leadership, dovevamo anche trovare il modo giusto per rendere disponibili queste API agli sviluppatori. Quando ho iniziato a lavorare su Chrome, ho commesso questo errore in un progetto chiamato API a livelli (o LAPIs in breve). Le API LAPIs mirano a offrire agli sviluppatori un'esperienza con componenti drop-in. Continuo a pensare che questo sia un ottimo risultato da raggiungere, ma abbiamo commesso molti errori. Ci siamo concentrati prima sulle notifiche di tipo Toast e su un elenco virtuale. I toast sono quasi impossibili da rendere accessibili e un elenco virtuale è uno dei componenti più difficili da realizzare correttamente. Le nostre intenzioni erano buone, ma il progetto non aiutava gli sviluppatori, quindi l'abbiamo ritirato. È difficile imparare nel modo più duro, ma ogni errore alimenta il rinascimento di CSS e HTML in corso.
Parliamo un po' di più delle API LAPIs. Che cosa è successo?
Nicole:per le API LAPIs, sapevamo che il web aveva bisogno di un'esperienza di sviluppo di componenti drop-in più simile alla creazione di UI native. Era chiaro che reinventare la ruota stava frenando gli sviluppatori. Non riesco a contare il numero di schede che ho creato nella mia carriera. Detto questo, abbiamo cercato di risolvere il problema distribuendo JavaScript con il browser, il che è stato molto difficile. Nessuno aveva mai integrato JavaScript nel browser prima e non era chiaro come dovesse interagire con il codice C++ che alimenta il motore di rendering del browser. Abbiamo ascoltato altri fornitori di browser (grazie, Mozilla!) e abbiamo abbandonato questo approccio, riuscendo così a trovare una soluzione molto migliore con Open UI. Utilizzando HTML e CSS, otteniamo soluzioni flessibili e dichiarative. Poiché è dichiarativo, possiamo integrare l'accessibilità in un modo che non sarebbe stato altrettanto semplice con JavaScript. Sono davvero entusiasta di dove stiamo andando. Stiamo lavorando per supportare selectmenu, popup, tooltip, nav, accordion, tabs, carousel e toggle, che sono pattern di progettazione dell'interfaccia utente davvero essenziali.
Quindi abbiamo imparato molto. So che ci sono state altre iniziative in questo spazio, come CSS Houdini. Qual è la storia?
Una: sì, CSS Houdini è un altro esempio di come abbiamo imparato dalla community. Esistono tantissime funzionalità Houdini utili, ma molte erano troppo di basso livello per ottenere un'adozione e un supporto più ampi. Ci siamo resi conto che l'implementazione di API di basso livello non riduceva necessariamente l'attrito per gli sviluppatori. Concentrarsi su soluzioni e esigenze di livello superiore ha contribuito a ottenere il supporto cross-browser e gli atterraggi necessari per far progredire l'ecosistema. Al momento stiamo monitorando i progressi all'indirizzo https://ishoudinireadyyet.com/.
A proposito di supporto cross-browser, iniziative come Interop 2022 e Open UI sembrano produrre risultati positivi significativi per la community. Cosa sentite dire dagli sviluppatori?
Una: uno dei principali problemi segnalati dagli sviluppatori è "far funzionare il design allo stesso modo su tutti i browser". Abbiamo affrontato questo problema collaborando con altri fornitori di browser per dare la priorità e implementare alcune delle funzionalità per sviluppatori più richieste. E il feedback che abbiamo ricevuto dalla community è stato estremamente positivo. Inoltre, grazie a un grande sforzo di riprogettazione chiamato RenderingNG, è diventato possibile implementare alcune di queste funzionalità in modo molto più efficiente. Gli sviluppatori sono entusiasti che queste funzionalità tanto attese che chiedono da anni siano finalmente in fase di sviluppo e vengano implementate su più browser.
Nicole: l'entusiasmo nella community è palpabile. Puoi vederlo su Twitter. :)
Collaborare con l'ecosistema si è rivelato fondamentale per il nostro successo nel semplificare la vita degli sviluppatori. So che il tuo team ha svolto un lavoro notevole. Vuoi condividere qualche dettaglio?
Nicole: innanzitutto, sono costantemente stupita dai progetti che gli sviluppatori creano sul web. Dalle librerie più piccole ai framework completi, gli sviluppatori stanno creando cose straordinarie. È una community fantastica di maker. Chrome sta adottando una serie di misure per essere più connesso a questi progetti.
Ad esempio, qualche anno fa abbiamo iniziato a lavorare con framework JavaScript come React e Angular. E i meta-framework, ad esempio Next, Nuxt e Gatsby. L'anno scorso abbiamo iniziato a fare lo stesso con strumenti e framework UI come Sass, Bootstrap e Material. Spero che il prossimo anno potremo collaborare con GreenSock e altri strumenti che semplificano la vita degli sviluppatori. Ho appena visto Cassie Evans di GreenSock parlare alla Smashing Conference e mi è venuta una gran voglia di lavorare con persone che si occupano di animazione.
Quindi, dove vediamo la maggiore opportunità per l'ecosistema dell'interfaccia utente web?
Una: in termini di grandi opportunità, mi sembra che stiamo solo grattando la superficie di ciò che è possibile per le esperienze web personalizzabili. Nuove API come le query sui contenitori e le funzionalità multimediali delle preferenze utente CSS stanno ridefinendo il modo in cui gli sviluppatori vedono il design adattabile. Sono entusiasta anche delle esperienze di progettazione collaborativa che consentono a sviluppatori e designer di lavorare all'unisono con gli utenti che visitano i loro siti web.
E Nicole, quali sono i prossimi passi del tuo team?
Nicole: non tutte le esplorazioni si trasformano in qualcosa di spedibile, ma ci sono molte cose che mi entusiasmano in questo momento:
Una ha parlato della prima cosa: stiamo attivando la progettazione reattiva basata su componenti. Include strumenti per la progettazione di sistemi di colori in modo che i designer possano rispondere alle preferenze degli utenti, come la modalità Buio. Ad esempio, lo spazio colore OKLCH mantiene la luminosità costante in tutte le tonalità. I designer possono passare dalla scelta dei colori alla progettazione delle relazioni tra i colori, senza ottenere tavolozze dall'aspetto opaco.
Stiamo anche lavorando ad alcune delle API più richieste, come le query sui contenitori, i livelli a cascata, il selettore principale (:has), gli stili con ambito e l'annidamento. Gli sviluppatori ne hanno bisogno per creare sistemi di progettazione flessibili pieni di componenti riutilizzabili.
Le animazioni collegate allo scorrimento sono un altro campo divertente. Mi piace molto la demo di Steve Gardner. Lo scorrimento è fluido e le animazioni degli aerei vengono attivate durante lo scorrimento. Anche se sono divertenti, può essere difficile realizzarli correttamente, soprattutto tenendo conto dell'accessibilità. Per questo motivo, stiamo eseguendo test di accessibilità sulla funzionalità.
La cosa che mi entusiasma di più personalmente sono i controlli dell'interfaccia utente web integrati. Gli sviluppatori continuano a creare lo stesso insieme di schede più e più volte. Penso che il browser possa aiutarli. In Open UI stiamo lavorando su componenti come selectmenu, popup, tooltip, schede, navigazione, accordion e toggle. Stiamo valutando la possibilità di integrare l'accessibilità in questi elementi di base del browser in modo che il web possa, nel tempo, diventare accessibile per impostazione predefinita. Gli sviluppatori possono quindi concentrarsi sui problemi più complessi e sfumati, mentre le basi, come la tabulazione delle schede, possono essere supportate dal browser. Probabilmente questo argomento merita un post a parte, quindi mi fermo qui per ora.
Infine, continueremo a investire nell'interoperabilità tra i browser. È stato fantastico collaborare con i team di WebKit e Gecko per rendere coerente l'esperienza degli sviluppatori. Gli sviluppatori ci hanno comunicato chiaramente che vogliono questa funzionalità.
E se non l'hai ancora provata, l'API Shared Element Transitions del team Seamless Web cambierà il modo in cui le persone progettano per il web. Tutte queste piccole transizioni sottili che consentono ai progettisti di orientare i loro progetti nello spazio fisico non solo saranno possibili, ma anche facili. Jake Archibald ha una demo fantastica.
Se gli standard vanno bene, potremmo persino esaminare il ritmo verticale quest'anno. Possiamo basarci su LayoutNG, che sblocca molte funzionalità.
Grazie a entrambi. Sono sicuro che l'intera community, come noi, è entusiasta di vedere il ritmo rinnovato di miglioramenti e funzionalità in arrivo nel mondo dell'interfaccia utente web. C'è ancora molto da capire, quindi da dove consigli di iniziare questo percorso?
Una: la sessione Novità della piattaforma web di I/O illustra i punti salienti di molte delle funzionalità in arrivo quest'anno. Adam Argyle ha anche scritto un ottimo articolo su tutte le nuove e imminenti pagine di destinazione CSS. Per il momento, mi concentrerei sulle release stabili e terrei d'occhio le altre attività in programma. La tua fantastica serie Novità sulla piattaforma web è un ottimo punto di partenza. L'iscrizione alla newsletter di web.dev porterà questi contenuti anche nella posta in arrivo degli sviluppatori. Per gli sviluppatori che vogliono partecipare e contribuire a tutto questo, unirsi a Open UI è uno dei modi migliori per supportare questo lavoro.
Principali aggiornamenti in arrivo
Continuiamo la nostra tradizione di avvisarti in anticipo di una modifica imminente da tenere presente durante la creazione delle tue esperienze web.
Limita max-age per i cookie a 400 giorni
- L'aggiornamento: quando i cookie vengono impostati con un attributo
Expires/Max-Ageesplicito, il valore verrà limitato a un massimo di 400 giorni in futuro. In precedenza non era previsto alcun limite e i cookie potevano scadere anche dopo millenni. Lo scopo di questo limite è trovare un equilibrio tra i pattern di utilizzo comuni e il rispetto della privacy degli utenti. Qualsiasi sito visitato più frequentemente di una volta ogni 400 giorni può aggiornare i cookie per garantire la continuità del servizio e gli utenti possono essere certi che i cookie non rimarranno nel browser per millenni senza essere utilizzati. - Cronologia stimata:spedizione in Chrome 104 (versione stabile il 2 agosto 2022).
- Invito all'azione per gli sviluppatori: gli sviluppatori potrebbero dover aggiornare in modo proattivo i cookie più spesso di prima quando gli utenti visitano i loro siti web. In caso contrario, gli utenti potrebbero uscire dall'account 400 giorni dopo l'impostazione iniziale del cookie.
Spero che la lettura di questa edizione di Chrome Dev Insider sia stata di tuo gradimento. Se l'hai perso, ecco il primo. Non vediamo l'ora di condividere altre novità nel prossimo trimestre.
Nel frattempo, facci sapere cosa pensi di questa edizione di Chrome Dev Insider e cosa possiamo fare per migliorarla.
Cosa ne pensi di questa edizione di The Chrome Dev Insider? Condividi il tuo feedback.