Hacker News nota il selettore di prefisso per classi CSS, ma la vera prova arriva dopo
Hacker News ha portato alla luce una proposta CSS che ha impiegato più di due anni per passare da un problema segnalato dagli sviluppatori a una direzione accettata dagli standard. Il selettore di prefisso per classi consentirebbe agli autori di abbinare token di classe distinti che condividono un prefisso, potenzialmente con una sintassi concisa come .icon-*.
Sembra una piccola comodità. Il conflitto più profondo riguarda se i browser debbano comprendere i modelli di denominazione già ampiamente usati da framework utility, librerie di icone e team applicativi.
Oggi gli autori devono elencare ogni classe correlata, aggiungere una classe base condivisa oppure affidarsi a una fragile soluzione alternativa con selettori di attributo. Il CSS Working Group ha accettato il caso d'uso sottostante, ma l'accettazione non equivale al supporto dei browser. Test, testo delle specifiche, lavoro di implementazione e interoperabilità separano ancora la proposta dai siti web in produzione.
Cosa ha effettivamente trovato Hacker News nella proposta CSS
La notizia non è che i browser abbiano improvvisamente distribuito un selettore wildcard per classi. Il cambiamento significativo è che il CSS Working Group ha accettato il problema.
Lea Verou ha aperto la relativa proposta CSSWG il 26 febbraio 2024. Ha descritto un'esigenza ricorrente: abbinare singoli nomi di classe che condividono un prefisso.
La issue è rimasta aperta mentre i partecipanti discutevano casi d'uso, sintassi e questioni più ampie sui selettori di attributo. Ora è chiusa con l'etichetta “Accepted by CSSWG Resolution” ed è assegnata a Selectors Level 5.
Questo stato è importante. Significa che il gruppo di lavoro ha concordato sul fatto che CSS debba affrontare il caso d'uso. Non significa che la notazione provvisoria .prefix-* sia diventata uno standard web stabile.
La issue riporta anche l'etichetta “Needs Testcase (WPT)”. WPT indica Web Platform Tests, la suite di test condivisa usata dai browser per verificare comportamenti interoperabili.
La sezione di sviluppo non elenca alcuna pull request associata. Anche la bozza pubblica di Selectors Level 5 non presenta ancora la funzionalità come un selettore completato e pronto per il deployment.
Questi dettagli definiscono l'evento reale. Una proposta di lunga data ha superato un'importante soglia degli standard, mentre la pipeline di implementazione resta incompleta.
La proposta si concentra sui token di classe, non sul testo arbitrario contenuto nell'attributo class completo. Questa distinzione spiega sia la sua utilità sia l'inadeguatezza delle attuali soluzioni alternative.
Consideriamo questo markup:
Uno sviluppatore potrebbe voler applicare una regola a ogni token di classe che inizia con icon-. La famiglia desiderata potrebbe includere icon-alert, icon-search e centinaia di icone aggiuntive.
Il selettore di prefisso per classi proposto esprime direttamente quella famiglia:
Questo esempio descrive il modello previsto, non una sintassi pronta per la produzione. Gli autori non dovrebbero distribuirla finché specifiche, test e browser non concordano sul suo comportamento.
Il selettore di attributo esistente sembra ingannevolmente simile:
Tuttavia, ^= verifica se il valore completo dell'attributo inizia con il testo fornito. Non esamina indipendentemente ogni token di classe.
La regola corrisponde a questo elemento:
Non corrisponde a questo:
Gli sviluppatori spesso compensano con due selettori:
Il primo gestisce un token corrispondente all'inizio. Il secondo cerca un token corrispondente dopo uno spazio.
Questo schema funziona nei casi HTML comuni, ma richiede agli sviluppatori di ragionare sul testo serializzato. Un selettore di classe dovrebbe ragionare sulle classi.
La proposta punta quindi a un divario reale tra il modello del documento e il linguaggio dei selettori. HTML tratta class come un insieme di token separati da spazi, mentre i selettori di sottostringhe operano sul valore serializzato dell'attributo.
L'elemento di Hacker News ha ricevuto sei punti e un commento nello snapshot fornito. Si tratta di una discussione limitata, quindi non può stabilire un ampio consenso tra gli sviluppatori.
Il suo valore risiede altrove. Il post ha richiamato l'attenzione su una decisione sugli standard che altrimenti potrebbe restare sepolta in una issue GitHub pluriennale.
Perché framework utility e librerie di icone avvertono la pressione
La proposta mette sotto pressione le librerie che oggi duplicano stili condivisi o richiedono markup aggiuntivo per rappresentare un'unica famiglia concettuale di classi.
I framework utility codificano relazioni tra proprietà e valori in nomi quali pt-6 o space-y-4. I sistemi di icone usano famiglie come fa-* e bi-*.
Questi sistemi di denominazione creano due tipi di stile. Ogni classe necessita di dichiarazioni specifiche per il proprio valore, mentre l'intera famiglia spesso condivide dichiarazioni di base.
Una famiglia di icone, per esempio, potrebbe necessitare di regole comuni per visualizzazione, dimensionamento, allineamento o rendering. Le singole classi di icona forniscono poi glifi o riferimenti a immagini distinti.
Senza l'abbinamento per prefisso, gli autori di librerie hanno diverse scelte imperfette. Possono elencare ogni classe, richiedere una classe base separata o manipolare la stringa completa dell'attributo.
L'enumerazione produce selettori come questo:
Uno strumento di build può generare tale elenco. La generazione riduce la digitazione, ma non elimina i byte generati né la relazione che gli autori devono mantenere.
Il secondo approccio separa il comportamento comune dal valore individuale:
Questo design è esplicito e spesso sensato. Richiede però ai consumatori di ricordare due classi per un singolo componente visibile.
Bootstrap Icons segue questo schema generale con una classe base bi e una classe di icona specifica. La proposta CSSWG usa sistemi di questo tipo come prova che il selettore mancante crea un attrito reale per gli autori.
Un selettore di prefisso per classi consentirebbe questo markup:
Il selettore della famiglia potrebbe fornire il comportamento condiviso, mentre .icon-alert fornisce la sua dichiarazione unica.
Questo non rende automaticamente superiore il markup con una sola classe. Le classi base possono comunicare l'intento, semplificare il debugging e impedire una regola di famiglia eccessivamente ampia.
La proposta offre invece agli autori un'altra rappresentazione. Le librerie potrebbero decidere se classi base esplicite o famiglie di prefissi inferite si adattino meglio ai loro contratti.
Il CSS utility-first crea una pressione correlata. Un prefisso come pt- codifica una categoria di proprietà, mentre il suffisso identifica un valore.
Un framework potrebbe usare un selettore di famiglia per stabilire una custom property condivisa, una regola di containment o un altro comportamento di base. Classi specifiche potrebbero poi fornire i singoli valori.
Il risparmio immediato potrebbe sembrare modesto. Il beneficio strutturale è più importante, perché il foglio di stile può esprimere lo stesso raggruppamento già incorporato nei nomi delle classi.
Ecco perché la proposta non è semplice zucchero sintattico. I cambiamenti di sintassi diventano architetturali quando permettono agli autori di rimuovere elenchi generati o markup ridondante.
Tuttavia, la funzionalità non sostituirebbe Tailwind, Bootstrap, Sass, PostCSS o l'estrazione in fase di build. Questi strumenti risolvono problemi molto più ampi dell'abbinamento di un prefisso di token.
Tailwind, per esempio, genera dichiarazioni basate su utility configurate e utilizzo rilevato. Un selettore nativo non genera la dichiarazione specifica del valore per ogni utility.
Il browser può abbinare .pt-*, ma non può dedurre il significato di ogni suffisso. Il foglio di stile necessita comunque di regole che mappino i nomi supportati a valori di proprietà validi.
Il selettore di prefisso per classi affronta quindi il raggruppamento, non la generazione arbitraria di utility. Le affermazioni secondo cui eliminerebbe gli strumenti di build CSS ne sopravvalutano la portata.
Il pubblico interessato si estende anche oltre i manutentori di framework. I team applicativi usano spesso nomi come status-*, theme-*, language-* o priority-*.
Un sistema di documentazione potrebbe emettere classi language-javascript e language-python sui blocchi di codice. La stessa specifica HTML raccomanda una convenzione di denominazione language- per gli esempi di codice.
I syntax highlighter devono quindi identificare il token della lingua anche quando altre classi lo precedono. Verou ha citato questo come un problema pratico per Prism.
I team che mantengono grandi frontend dovrebbero interessarsene, perché le convenzioni diventano infrastruttura. Quando migliaia di template dipendono da un modello di denominazione, ogni soluzione alternativa diventa più difficile da modificare.
Il mantenimento di queste decisioni richiede anche una documentazione interna affidabile. Una base di conoscenza ingegneristica ricercabile può conservare le convenzioni sui selettori insieme a note sui componenti e sulle migrazioni.
La decisione sugli standard pone i manutentori di framework e librerie sotto pressione a lungo termine, non sotto pressione per una migrazione immediata. Devono decidere se le relazioni di prefisso siano contratti pubblici significativi.
Il meccanismo risolve l'abbinamento dei token, non solo una sintassi più breve
Il meccanismo centrale è l'abbinamento di prefissi consapevole dei token, che differisce sostanzialmente dalla ricerca nel testo grezzo di un attributo `class`.
CSS include già diversi selettori di attributo. La specifica dei selettori definisce operatori per valori esatti, token separati da spazi, prefissi, suffissi e sottostringhe.
Ogni operatore risponde a una domanda diversa. [class~="button"] trova un token button completo, mentre [class^="button-"] verifica l'inizio del valore completo dell'attributo.
Ciò che manca a CSS è un'operazione combinata. Gli autori devono selezionare un token da un elenco separato da spazi e poi verificare se quel token inizia con un prefisso.
La issue originale ha considerato due strade. Una estende il familiare selettore di classe con sintassi wildcard, come .foo-*.
L'altra aggiunge un operatore di attributo che combina il comportamento di ~= e ^=. Le forme proposte includevano ~^=, ^~= e ^~.
La notazione di classe è più facile da leggere perché resta nel vocabolario esistente dei selettori di classe di CSS. Una regola che inizia con un punto comunica chiaramente che si rivolge alle classi.
L'operatore di attributo combinato sarebbe più generale. Potrebbe applicarsi ad attributi diversi da class quando tali attributi contengono valori separati da spazi.
La generalità comporta costi propri. Un nuovo operatore deve inserirsi nelle regole di parsing CSS, restare comprensibile ed evitare di confondere gli autori che già imparano diversi operatori di attributo.
La sintassi wildcard per classi solleva anche questioni che vanno oltre l'estetica. La specifica deve definire escaping, confini di abbinamento, sensibilità alle maiuscole/minuscole, input non validi e specificità.
La specificità determina quale dichiarazione prevale quando corrispondono più selettori. Un nuovo selettore necessita di un comportamento prevedibile accanto a classi ordinarie, attributi, pseudo-classi e regole annidate.
Il processo di standardizzazione deve anche decidere come il selettore si comporti tramite le API del browser. querySelector(), matches() e il parsing dei fogli di stile consumano tutti sintassi di selettori.
Il comportamento dei selettori non validi è importante perché una sintassi non supportata può invalidare un elenco di selettori. Gli autori hanno bisogno di un modo affidabile per usare la funzionalità senza eliminare accidentalmente regole non correlate.
Il rilevamento delle funzionalità è un'altra questione pratica. CSS supporta @supports selector(...) per verificare se un browser riconosce un selettore.
Un futuro schema di progressive enhancement potrebbe assomigliare a questo:
Questa illustrazione resta ipotetica finché la grammatica finale non verrà pubblicata. Dimostra perché i dettagli di parsing siano importanti prima che gli sviluppatori possano scrivere fallback sicuri.
Le questioni di prestazioni meritano un trattamento accurato, ma non dovrebbero diventare speculazione. I browser mantengono già meccanismi ottimizzati per l'abbinamento di classi e attributi.
Un'operazione di prefisso consapevole dei token non è automaticamente lenta. Il suo costo dipende dalle strategie di indicizzazione dei motori, dai modelli dei fogli di stile e dalle scelte finali della specifica.
Allo stesso modo, la funzionalità non obbliga intrinsecamente i browser a eseguire la scansione di ogni classe su ogni elemento per ogni ricalcolo dello stile. Gli implementatori possono sviluppare indici e scorciatoie di abbinamento.
Solo i prototipi dei browser e i Web Platform Tests possono convalidare queste ipotesi. L’accettazione da parte degli standard fornisce una direzione, non prove sulle prestazioni.
L’argomento più forte della proposta è l’allineamento semantico. Gli sviluppatori pensano a class="card icon-alert muted" come a tre token, non a un’unica stringa contenente spazi.
Il normale .icon-alert utilizza già quel modello a token. Estenderlo a una famiglia di classi mantiene coerente il modello mentale.
Questa aderenza semantica migliora anche la verificabilità in fase di revisione. .icon-* rivela immediatamente uno spazio dei nomi o una famiglia prevista, mentre una soluzione alternativa basata su attributi richiede un’analisi più attenta.
Tuttavia, una sintassi concisa può nascondere un ambito di corrispondenza molto ampio. Una singola regola di famiglia potrebbe influire su ogni classe che inizia con un prefisso breve all’interno di un’applicazione.
Non è un difetto del parser. È un problema di governance dei fogli di stile, simile ai selettori di tipo troppo generici o alle proprietà personalizzate dai nomi poco specifici.
Il meccanismo offre a CSS un primitivo più pulito. Non stabilisce se un team userà quel primitivo con attenzione.
Il vero rischio è un CSS permeabile, non il carattere jolly
Un selettore di prefisso può ridurre il codice fragile rendendo più facile l’accoppiamento accidentale, quindi la disciplina nella denominazione diventa più importante dopo l’adozione.
La reazione scettica è semplice. Se un selettore corrisponde a una famiglia aperta, una classe futura può ereditare stili che il suo autore non si sarebbe mai aspettato.
Supponiamo che un design system definisca questa regola:
Mesi dopo, un altro team aggiunge card-payment-error per analisi o stato dell’applicazione. Quella classe entrerebbe nella famiglia di stili pur avendo uno scopo diverso.
Una classe base evita questa ambiguità:
Il markup dichiara che l’elemento è una card. La classe specifica aggiunge un significato separato.
La corrispondenza per prefisso deduce l’appartenenza dalla grafia. Può essere concisa, ma trasforma le convenzioni di denominazione in relazioni eseguibili.
La distinzione ricorda la tipizzazione strutturale nella programmazione. Un nome è idoneo perché ha la forma attesa, non perché l’autore ne abbia dichiarato esplicitamente l’appartenenza.
Questo può funzionare bene all’interno di spazi dei nomi controllati. Diventa rischioso quando prefissi brevi attraversano prodotti, moduli legacy, widget di terze parti o team gestiti in modo indipendente.
La preoccupazione è emersa nelle prime reazioni pubbliche al post collegato. Un commentatore su Reddit ha riassunto il timore come maggiori opportunità per un “leaky css”.
Quella reazione non è una prova contro lo standard. Identifica il compromesso che le specifiche non possono risolvere per i team applicativi.
Le librerie dovranno documentare le famiglie di prefissi come API stabili. Una volta che .icon-* condivide un comportamento, ogni nuova classe che inizia con icon- entra in quel contratto.
Anche il refactoring diventa meno locale. Rinominare una classe può modificare sia la sua regola specifica sia qualsiasi regola di famiglia con carattere jolly che le corrisponde.
Gli strumenti per sviluppatori dovranno rendere chiare queste relazioni. Un inspector dovrebbe mostrare che .icon-alert ha corrisposto a un selettore di famiglia, non soltanto al suo selettore esatto.
Gli strumenti di ricerca, i linter e l’intelligenza del codice potrebbero richiedere aggiornamenti analoghi. L’analisi statica diventa più difficile quando un selettore rappresenta un insieme in espansione anziché un nome fisso.
La proposta potrebbe anche incoraggiare gli autori a codificare più dati nei nomi delle classi. Questo schema è già comune, ma il supporto nativo potrebbe aumentarne l’attrattiva.
I partecipanti del CSSWG si sono chiesti se alcune relazioni chiave-valore non appartengano invece agli attributi data-*. Per esempio, data-pt="6" rende proprietà e valore strutturalmente separati.
Questa rappresentazione è più esplicita, ma anche più prolissa. Potrebbe non integrarsi con le convenzioni dei framework esistenti o con gli strumenti basati sulle classi.
Nessuno dei due modelli prevale universalmente. Le classi restano appropriate per raggruppamenti e hook di stile, mentre gli attributi data possono rappresentare stato o dati dell’applicazione.
Il selettore di prefisso per classi non dovrebbe diventare una scusa per spostare ogni stato in un nome di classe compresso. La corrispondenza nativa non elimina le scelte di progettazione semantica.
Esiste inoltre un rischio di compatibilità durante la transizione. Gli autori non possono presumere che l’accettazione da parte degli standard significhi che la sintassi funzioni in tutti i browser.
Usare un selettore non riconosciuto senza un fallback può rimuovere silenziosamente gli stili previsti. L’adozione in produzione dovrebbe attendere supporto documentato e prove di interoperabilità.
Gli sviluppatori dovrebbero anche evitare di copiare sintassi illustrative prima che si stabilizzino. La issue ha proposto .foo-*, ma i gruppi di lavoro possono rivedere la grammatica durante la modifica di una specifica.
Anche dopo che un motore ha implementato la funzionalità, i team dovrebbero verificare se gli altri motori gestiscono i casi limite in modo identico. La storia di CSS include funzionalità che hanno impiegato anni per raggiungere un’interoperabilità affidabile.
L’impostazione di Hacker News può comprimere queste fasi in un unico titolo. “Future CSS” è corretto, mentre “nuovo CSS che puoi usare ora” sarebbe fuorviante.
Un team applicativo prudente dovrebbe continuare a usare classi base esplicite quando quella struttura comunica un significato importante. Gli elenchi di selettori generati restano validi quando la famiglia di classi è finita.
L’attuale soluzione alternativa basata su attributi resta utilizzabile in markup controllato. Gli autori devono ricordare che si basa su spazi bianchi e serializzazione degli attributi, anziché sulla semantica diretta dei token.
Nessuna singola regola di migrazione è adatta a ogni codebase. La funzionalità migliora il linguaggio disponibile, ma è comunque l’architettura a stabilire se migliora l’applicazione.
Cosa deve accadere prima che il selettore di prefisso per classi venga rilasciato
Tre segnali determineranno se l’idea accettata diventerà CSS affidabile: testo della specifica, test condivisi e implementazioni interoperabili nei browser.
Il primo segnale è una modifica concreta a Selectors Level 5. La bozza necessita di grammatica normativa e regole di corrispondenza, non soltanto di una risoluzione GitHub collegata.
Il testo normativo definisce ciò che le implementazioni conformi devono fare. Dovrebbe chiarire la forma del selettore, i confini dei token, l’escaping, la specificità e il comportamento nelle API dei selettori.
Quella modifica rafforzerebbe l’ipotesi che .prefix-*, o una sintassi successiva, stia avanzando verso l’implementazione. Una grammatica diversa indebolirebbe le supposizioni basate sugli esempi attuali.
Il secondo segnale è il progresso nei Web Platform Tests. L’etichetta di test della issue mostra che il gruppo di lavoro si aspetta una copertura eseguibile.
I test dovrebbero includere classi in diverse posizioni nell’attributo, più token corrispondenti, caratteri con escape, comportamento rispetto alle maiuscole e minuscole e sintassi non valida.
Dovrebbero inoltre coprire le API JavaScript dei selettori. Una funzionalità CSS resta incompleta se i fogli di stile e querySelector() non concordano sulla stessa grammatica.
Un’ampia suite di test rafforzerebbe la fiducia nel fatto che i team dei browser condividano un’unica interpretazione. Test mancanti o modificati ripetutamente indicherebbero dettagli di progettazione irrisolti.
Il terzo segnale è l’implementazione nei motori dei browser. Una build sperimentale può rivelare la fattibilità, ma non può stabilire la compatibilità sul web.
Gli sviluppatori dovrebbero seguire i tracker delle issue di Chromium, Gecko e WebKit per i lavori di implementazione. Le note di rilascio e i dati di compatibilità conteranno più dell’attenzione sui social.
La disponibilità tra più motori rafforzerebbe il valore architetturale della proposta. Un supporto a lungo termine in un solo motore la manterrebbe nel territorio del progressive enhancement.
Gli esperimenti dei framework forniscono un ulteriore indizio di adozione, sebbene seguano quei tre segnali tecnici. I maintainer possono verificare se un selettore di famiglia riduce l’output o semplifica il markup pubblico.
Le misurazioni utili includono la dimensione dei selettori generati, la complessità della build, il costo della migrazione e la chiarezza nel debugging. Questi risultati contano più del numero di caratteri in un singolo selettore.
L’adozione da parte dei framework non è necessaria perché la funzionalità abbia successo. Design system più piccoli, librerie di icone ed evidenziatori di sintassi possono beneficiarne indipendentemente.
L’esempio delle classi di linguaggio HTML potrebbe diventare particolarmente istruttivo. Verifica se la corrispondenza consapevole dei token migliora una convenzione consolidata al di fuori dello styling utility-first.
Gli sviluppatori non dovrebbero aspettarsi che la proposta produca un pattern matching arbitrario. La discussione riguarda prefissi su singoli token di classe, non espressioni regolari all’interno di CSS.
Dovrebbero anche evitare di presumere che i caratteri jolly per suffissi e sottostringhe arriveranno simultaneamente. I progetti di caratteri jolly più ampi richiedono una giustificazione e un lavoro di specifica separati.
Per ora, il codice di produzione dovrebbe trattare il selettore come una direzione accettata ma in sviluppo. I team possono valutare le convenzioni di denominazione senza distribuire sintassi non supportata.
Questa preparazione può comunque essere utile. Verificate se i prefissi rappresentano famiglie intenzionali, somiglianze accidentali o una combinazione di entrambe.
Documentate quali prefissi funzionano come contratti pubblici di stile. Individuate i punti in cui una classe base comunica un significato che l’inferenza nasconderebbe.
Testate le soluzioni alternative basate su attributi rispetto a classi riordinate e spazi bianchi inattesi. Molte codebase scopriranno che la loro presunta corrispondenza per prefisso dipende dalla posizione del token.
Quando arriverà il supporto nativo, la migrazione dovrebbe iniziare con spazi dei nomi ristretti e ben gestiti. Le famiglie di icone e gli identificatori di linguaggio generati offrono confini più chiari rispetto ai prefissi generici.
Usate il rilevamento delle funzionalità finché il supporto resta disomogeneo. Mantenete i fallback finché i dati di compatibilità non mostrano che i browser usati dal vostro pubblico si comportano in modo coerente.
Hacker News tornerà probabilmente sul selettore quando apparirà un prototipo di browser. Quella discussione successiva dovrebbe concentrarsi su test, comportamento e interoperabilità, anziché sulla sola novità.
L’importanza della proposta deriva da uno schema ricorrente nel CSS moderno. I browser stanno assorbendo capacità che gli autori un tempo approssimavano con preprocessori, codice generato o fragili trucchi con i selettori.
Questo cambiamento è più circoscritto di nesting, container queries o :has(). Il suo ambito limitato può essere un vantaggio perché il problema e il comportamento previsto sono insolitamente concreti.
Anche il lavoro rimanente è concreto. Gli editor devono scrivere la regola, gli autori dei test devono catturarne i casi limite e i team dei browser devono implementare lo stesso risultato.
Se questi passaggi si allineano, gli sviluppatori ottengono un modo diretto per selezionare più classi CSS tramite prefisso. Se divergono, le classi base esplicite restano il contratto più sicuro.
L’azione corretta oggi è l’osservazione, non la sostituzione immediata. Esaminate la proposta, ispezionate gli spazi dei nomi delle vostre classi e individuate dove la corrispondenza consapevole dei token eliminerebbe costi di manutenzione reali.
Poi osservate i tre segnali nell’ordine indicato: testo normativo della specifica, test completi e implementazioni in più browser. Quale famiglia di prefissi nella vostra codebase offrirebbe il test di interoperabilità più chiaro?
