Il gruppo di lavoro CSS al TPAC: cosa c'è di nuovo nei CSS?

La scorsa settimana, ho partecipato al W3C TPAC e alla riunione del CSS Working Group lì. Sono state apportate varie modifiche alle specifiche e si sono svolte discussioni che ritengo siano di interesse per i web designer e gli sviluppatori. In questo articolo, spiegherò un po' cosa succede al TPAC e mostrerò alcuni esempi e demo delle cose di cui abbiamo discusso al TPAC per CSS in particolare.

Cos'è il TPAC?

TPAC è la settimana delle riunioni del comitato tecnico plenario / consultivo del W3C. Un'occasione per riunire sotto lo stesso tetto tutti i vari gruppi di lavoro che fanno parte del W3C. L'evento si svolge ogni anno in una parte diversa del mondo, quest'anno si è tenuto a Lione, in Francia. Al TPAC, i gruppi di lavoro come il CSS Working Group hanno le proprie riunioni, proprio come facciamo in altri periodi dell'anno. Tuttavia, poiché siamo tutti in un edificio, significa che persone di altri gruppi possono venire più facilmente come osservatori e possono essere discussi gli interessi dei gruppi di lavoro incrociati.

I partecipanti al TPAC sono in genere membri di uno o più gruppi di lavoro, che lavorano sulle tecnologie del W3C. Saranno rappresentanti di un'organizzazione membro o Esperti invitati. Come per qualsiasi altra riunione dei gruppi di lavoro del W3C, i verbali di tutte le discussioni tenute al TPAC saranno disponibili pubblicamente, di solito come registri IRC scritti durante le riunioni.

Il gruppo di lavoro CSS

Il Gruppo di lavoro CSS si incontra faccia a faccia al TPAC e in almeno altre due occasioni durante l'anno; questo è in aggiunta alle nostre telefonate settimanali. In tutti i nostri incontri, vengono discusse le varie questioni sollevate sulle specifiche e vengono prese le decisioni. Alcuni problemi vengono mantenuti per le discussioni faccia a faccia a causa dei vantaggi di poterli avere con l'intero gruppo o semplicemente di poter aggirare una lavagna o vedere una demo sullo schermo.

Quando un problema viene discusso in qualsiasi riunione (sia faccia a faccia che in teleconferenza), il problema GitHub pertinente viene aggiornato con il verbale della discussione. Ciò significa che se hai un problema di cui vuoi tenere traccia, puoi aggiungerlo a Speciali e vedere quando viene aggiornato. I verbali completi dell'IRC sono anche inviati alla mailing list in stile www.

Ecco una selezione delle cose di cui abbiamo discusso che penso ti interesseranno di più.

Barre di scorrimento CSS

La specifica CSS Scrollbars cerca di fornire un modo standard per definire le dimensioni e il colore delle barre di scorrimento. Se hai Firefox Nightly, puoi provarlo. Per vedere gli esempi seguenti, usa Firefox Nightly e abilita i flag layout.css.scrollbar-width.enabled e layout.css.scrollbar-color.enabled visitando https://about:config in Firefox Nightly.

La specifica fornisce due nuove proprietà: scrollbar-width e scrollbar-color . La proprietà scrollbar-width può assumere un valore di auto , thin , none o length (come 1em ). Sembra che il valore della length possa essere rimosso dalla specifica. Come puoi immaginare, sarebbe possibile per uno sviluppatore web creare una barra di scorrimento molto inutilizzabile giocando con la larghezza, quindi potrebbe essere meglio consentire al browser di decidere la larghezza esatta che ha senso ma invece mostrare sottile o spessa barre di scorrimento. Firefox non ha implementato l'opzione di lunghezza.

Se utilizzi auto come valore, il browser utilizzerà le barre di scorrimento predefinite: thin ti darà una barra di scorrimento sottile e none mostrerà nessuna barra di scorrimento visibile (ma l'elemento sarà comunque scorrevole).

In un browser con supporto per CSS Scrollbars, puoi vederlo in azione nella demo:

La proprietà scrollbar-color si occupa, come ci si aspetterebbe, dei colori della barra di scorrimento. Una barra di scorrimento ha due parti che potresti voler colorare indipendentemente:

• pollice
  Il cursore che si muove su e giù mentre scorri.
• traccia
  Lo sfondo della barra di scorrimento.

I valori per la proprietà scrollbar-color sono auto , dark , light e <color> <color> .

L'uso auto come valore della parola chiave ti darà i colori della barra di scorrimento predefiniti per quel browser, dark fornirà una barra di scorrimento scura, nella modalità scura di quella piattaforma o in una modalità scura personalizzata, light la modalità chiara della piattaforma o una modalità chiara personalizzata .

Per impostare i tuoi colori, aggiungi due colori come valore separati da uno spazio. Il primo colore sarà utilizzato per il pollice e il secondo per la traccia . Dovresti fare attenzione che ci sia abbastanza contrasto tra i colori, altrimenti la barra di scorrimento potrebbe essere difficile da usare per alcune persone.

In un browser con supporto per CSS Scrollbars, puoi vedere questo nella demo:

Unità di rapporto di aspetto

Utilizziamo da tempo l'hack del riempimento nei CSS per ottenere le proporzioni delle caselle, tuttavia, con l'avvento di Grid Layout e modi migliori per ridimensionare il contenuto, avere un modo reale per fare le proporzioni nei CSS è diventato un'esigenza più urgente .

Ci sono due problemi sollevati su GitHub che si riferiscono a questo requisito:

• Unità di rapporto d'aspetto necessarie
• Proporzioni.

Ora c'è una bozza di specifica nel livello 4 di CSS Sizing e la decisione della riunione è stata che ciò richiedeva un'ulteriore discussione su GitHub prima di poter prendere qualsiasi decisione. Quindi, se sei interessato a questo o hai altri casi d'uso, il CSS Working Group sarebbe interessato ai tuoi commenti su tali questioni.

La pseudoclasse funzionale :where()

L'anno scorso, il CSSWG ha deciso di aggiungere una pseudo-classe che si comportava come :matches() ma con zero specificità, rendendo così facile l'override senza dover gonfiare artificialmente la specificità degli elementi successivi per sovrascrivere qualcosa in un foglio di stile predefinito.

La pseudo-classe :matches() potrebbe essere nuova per te in quanto è un selettore di livello 4, tuttavia ti consente di specificare un gruppo di selettori a cui applicare alcuni CSS. Ad esempio potresti scrivere:

 .foo a:hover, pa:hover { color: green; }

O con :matches()

 :matches(.foo, p) a:hover { color: green; }

Se hai mai avuto una grande pila di selettori solo per impostare lo stesso paio di regole, vedrai quanto sarà utile. Il seguente CodePen usa i nomi prefissi di webkit webkit-any e -moz-any per dimostrare la funzionalità di matches() . Puoi anche leggere di più su match() su MDN.

Dove spesso eseguiamo questo tipo di impilamento dei selettori, e quindi dove :matches() sarà più utile è in una sorta di foglio di stile iniziale predefinito. Tuttavia, è necessario prestare attenzione quando si sovrascrivono tali impostazioni predefinite che qualsiasi sovrascrittura avvenga in modo da garantire che sia più specifico delle impostazioni predefinite. È per questo motivo che è stata proposta una versione a specificità zero.

La questione che è stata discussa durante la riunione riguardava la denominazione di questa pseudo-classe, puoi vedere la risoluzione finale qui, e se ti chiedi perché sono stati esclusi vari nomi, dai un'occhiata al thread completo. Dare un nome alle cose in CSS è molto difficile, perché tutti dovremo conviverci per sempre! Dopo un lungo dibattito, il gruppo ha votato e ha deciso di chiamare questo selettore :where() .

Dall'incontro, e mentre stavo scrivendo questo post, è stato sollevato un suggerimento per rinominare matches() in is() . Dai un'occhiata al problema e commenta se hai sentimenti forti in ogni caso!

Scorciatoie logiche per margini e riempimento

In merito alla denominazione delle cose, in passato ho scritto di proprietà e valori logici qui su Smashing Magazine, dai un'occhiata a "Comprendere proprietà e valori logici". Queste proprietà e valori forniscono mappature relative al flusso. Ciò significa che se si utilizzano modalità di scrittura diverse da una modalità di scrittura orizzontale dall'alto verso il basso, come l'inglese, elementi come margini e spaziatura interna, larghezza e altezza seguono la direzione del testo e non sono collegati alle dimensioni fisiche dello schermo.

Ad esempio, per i margini fisici abbiamo:

• margin-top
• margin-right
• margin-bottom
• margin-left

Le mappature logiche per questi (assumendo horizontal-tb) sono:

• margin-block-start
• margin-inline-end
• margin-block-end
• margin-inline-start

Possiamo avere due scorciatoie di valore. Ad esempio, per impostare sia margin-block-start che margin-block-end come abbreviazione, possiamo usare margin-block: 20px 1em . Il primo valore rappresenta lo spigolo iniziale nella dimensione del blocco, il secondo valore lo spigolo finale nella dimensione del blocco.

Abbiamo riscontrato un problema, tuttavia, quando arriviamo al margin shorthand a quattro valori. Quel nome di proprietà viene utilizzato per i margini fisici: come denotiamo la versione logica a quattro valori? Sono state suggerite varie cose, incluso un interruttore nella parte superiore del file:

 @mode "logical";

Oppure, per utilizzare un blocco che assomiglia un po' a una query multimediale:

 @mode (flow-mode: relative) { }

Quindi vari suggerimenti per modificatori di parole chiave, utilizzando alcuni caratteri di punteggiatura o creando un nome di proprietà nuovo di zecca:

 margin: relative 1em 2em 3em 4em; margin: 1em 2em 3em 4em !relative; margin-relative: 1em 2em 3em 4em; ~margin: 1em 2em 3em 4em;

Puoi leggere il problema per vedere le varie cose che vengono prese in considerazione. I problemi discussi erano che mentre la versione logica potrebbe finire per essere generalmente l'impostazione predefinita, a volte vorrai che le cose si riferissero alla geometria dello schermo; dobbiamo essere in grado di avere entrambe le opzioni in un foglio di stile. Avere un'impostazione @mode nella parte superiore del CSS potrebbe creare confusione; fallirebbe se qualcuno dovesse copiare e incollare un pezzo del foglio di stile.

La mia preferenza è avere una sorta di valore per la parola chiave. In questo modo, se guardi la regola, puoi vedere esattamente quale modalità viene utilizzata, anche se sembra leggermente inelegante. È il genere di cose che un preprocessore potrebbe affrontare per te; se davvero volevi che tutte le tue proprietà e valori utilizzassero le versioni logiche.

Non siamo riusciti a risolvere il problema, quindi se hai pensieri su quale di questi potrebbe essere il migliore, o se vedi problemi con loro che non abbiamo descritto, commenta il problema su GitHub.

Discussione sui test della piattaforma Web

Alla riunione del gruppo di lavoro CSS e poi durante la giornata plenaria tecnica in stile non conferenza, sono stato coinvolto nella discussione su come coinvolgere più persone nella scrittura di test per le specifiche CSS. Il progetto Web Platform Tests mira a fornire test per tutta la piattaforma web. Questi test aiutano quindi i fornitori di browser a verificare se il loro browser è corretto rispetto alle specifiche. Nel CSS Working Group, l'obiettivo è che qualsiasi modifica normativa a una specifica che ha raggiunto lo stato di Candidate Recommendation (CR) sia accompagnata da un test. Questo ha senso poiché una volta che una specifica è in CR, chiediamo ai browser di implementare quella specifica e fornire feedback. Hanno bisogno di sapere se qualcosa nelle specifiche cambia in modo da poter aggiornare il loro codice.

Il problema è che abbiamo pochissime persone che scrivono le specifiche, quindi per chi scrive le specifiche dover scrivere tutti i test rallenterà il progresso dei CSS. Ci piacerebbe vedere altre persone scrivere test, poiché è un modo per contribuire alla piattaforma web e per acquisire una profonda conoscenza del funzionamento delle specifiche. Quindi ci siamo incontrati per pensare a come incoraggiare le persone a partecipare allo sforzo. Ho scritto su questo argomento in passato; se l'idea di scrivere dei test per la piattaforma ti interessa, dai un'occhiata al mio articolo 24 Ways su “Testing the Web Platform”.

Avanti con il lavoro!

TPAC ha aggiunto considerevolmente alla mia lista di cose da fare. Tuttavia, sono stato in grado di raccogliere suggerimenti sulla modifica delle specifiche, sulla scrittura di test e su un piano per riportare la specifica del layout a colonne multiple, di cui sono il co-editore, allo stato CR. Come persona che non è un fan delle riunioni, sono arrivato a vedere quanto siano preziosi questi incontri faccia a faccia per la piattaforma web, dando a coloro di noi che contribuiscono ad essa la possibilità di condividere le conoscenze che stiamo sviluppando individualmente. Ritengo sia importante, tuttavia, prendere quella conoscenza e condividerla al di fuori del gruppo per aiutare più persone a essere coinvolte nello sviluppo e nell'utilizzo della piattaforma.

Se sei interessato a come funziona il CSS Working Group e come i nuovi CSS vengono inventati e finiscono nei browser, dai un'occhiata alla mia presentazione CSSConf.eu 2017 "Da dove viene il CSS?" e le informazioni di fantasai nei suoi post “An Inside View of the CSS Working Group at W3C”.