Matías Ventura, capo del progetto Gutenberg, ha annunciato il Strada preliminare a 5.9 sul blog Make Core prima di oggi. Ha coperto diversi quadro generale elementi, inclusi diversi sottopunti per ciascuno. Ha anche legato a a Problema con GitHub con compiti e ticket specifici che necessitano di lavoro.
Il post copre note su schemi di blocco, menu di navigazione, il theme.json interfaccia (stili globali), strumenti di progettazione e flussi di modifica per i temi dei blocchi. Ci sono molte informazioni da acquisire e aree sufficienti per coprire vari interessi.
L’obiettivo più entusiasmante di 5.9 potrebbe essere quello di approfondire il design reattivo a livello di blocco, che si tratti di codice nascosto o di opzioni di blocco disponibili tramite l’interfaccia utente.
“Uno dei maggiori punti di attrito per i costruttori di modelli e temi è la mancanza di strumenti reattivi disponibili a livello di blocco”, ha scritto Ventura. “Questo deve essere risolto in un modo che non aumenti in modo sproporzionato la complessità dell’interfaccia.”
Web design intrinseco con blocchi
È facile essere scontenti dei lenti progressi verso opzioni di blocco reattive negli ultimi anni. Non sono del tutto scontento perché voglio che il team sia metodico e si avvicini a questo in un modo a prova di futuro, almeno nella misura in cui può.
Troppo spesso, quello che abbiamo visto con le richieste e persino con i plug-in di terze parti è l’uso di query multimediali basate su viewport per controllare il modo in cui i blocchi rispondono a diversi dispositivi (ad esempio desktop, tablet e dispositivi mobili). Sebbene tali controlli a volte possano essere lo strumento giusto per il lavoro, non sono sempre il percorso corretto per la progettazione basata sui componenti.
Le media query tendono a favorire metodologie di progettazione olistiche. Tuttavia, il design basato su componenti è il volto moderno del web. I blocchi sono solo un altro componente e, poiché gli sviluppatori o anche gli utenti possono posizionarli ovunque nel design generale, dobbiamo avvicinarci al modo in cui rispondono all’ambiente circostante più che alla finestra del browser.
“Il modello a blocchi è un buon caso per applicare alcuni principi di progettazione intrinseci, poiché un blocco può occupare un posto in molti layout e contenitori diversi, per i quali le query media prescrittive che non tengono conto del contesto sono inflessibili”, ha scritto Ventura.
Un semplice esempio da guardare è il blocco principale delle colonne di WordPress. Potremmo facilmente aggiungere opzioni di query multimediali per quando ogni blocco Colonna interno si interrompe. Tuttavia, come dovrebbe rispondere la tipografia per tre colonne contro quattro e con larghezze diverse? Questa è una funzione della dimensione del contenitore piuttosto che del viewport.
E come funzionano tali media query quando le colonne sono nidificate all’interno di un’altra colonna? Questo diventa un problema più complesso da risolvere se si mettono i controlli del layout nelle mani degli utenti. Spingere il pulsante di avanzamento rapido sulle opzioni di blocco reattivo potrebbe essere piacevole al momento, ma potrebbe anche creare un bagaglio legacy che sarà difficile da abbandonare quando si troverà una soluzione migliore.
Anche qualcosa di apparentemente semplice come l’intestazione di un sito Web di base può diventare complesso durante la progettazione per l’input dell’utente. Per i designer di temi, non c’è modo di sapere quanti caratteri ci sono nel titolo del sito, ad esempio, o quanti elementi ci sono nel menu di navigazione. Il sistema a blocchi può complicare ulteriormente le cose consentendo agli utenti finali di inserire altre incognite.
“Ogni area del blocco dovrebbe essere intrinsecamente reattiva, consentendo ai blocchi di comporre insieme, avvolgere, impilare e organizzarsi per adattarsi ai diversi spazi e schermi”, ha scritto Ventura. “Affinché funzioni bene, i blocchi contenitore devono assorbire più controlli di layout”.
Ha anche menzionato query contenitore come possibile punto di espansione quando saranno completamente supportati dai browser in futuro. Chrome Canary ha attualmente un flag di supporto per abilitare la funzione.
Le query sui container sono un po’ il Santo Graal per i designer. Come web designer Ethan Marcotte ha scritto quattro anni fa:
Forse comincerò da qui: negli ultimi anni il mio lavoro di progettazione si è concentrato molto più sui pattern, e meno sulle “pagine”. Invece di trattare un design reattivo come una cosa olistica e unificata, in cui ogni parte del layout cambia e si adatta alla stessa velocità, è più utile suddividere un layout reattivo in pezzi di design più piccoli e riutilizzabili, inclusi elementi come “testata, ” “piè di pagina”, “didascalia dell’immagine” e così via.
In altre parole, il mio processo di progettazione prevede di considerare un design reattivo come una rete di piccoli sistemi di layout. Ciascuno di questi componenti è sostanzialmente un piccolo design reattivo, con i propri set di punti di interruzione.
Suona familiare? Sì, il sistema a blocchi di WordPress è costruito sulla stessa base di piccoli componenti di layout.
Tutto ciò che WordPress fa oggi a livello di interfaccia utente deve tenere conto delle query del contenitore del futuro. O, almeno, fare uso di strumenti esistenti che potrebbero replicare la funzione in qualche modo, come il min(), max(), e clamp() Funzioni CSS.
Il problema è capire quali funzionalità dovrebbero essere esposte come opzioni di blocco anziché essere gestite sotto il cofano. Il team di sviluppo deve trovare un equilibrio tra l’esperienza dell’utente e la flessibilità per i progettisti. Alcune cose dovrebbero “funzionare” immediatamente e altre dovrebbero essere configurabili caso per caso.
Questo dovrebbe essere uno dei problemi più interessanti, complessi, frustranti e gratificanti da risolvere nel ciclo WordPress 5.9. Per chi cerca una sfida, potrebbe essere il punto di ingresso perfetto.