TablesNG risolve 72 bug di Chromium per una migliore interoperabilità

Aleks Totic
Aleks Totic

TablesNG viene lanciato in Chromium 91 e corregge una serie di bug che fanno parte della piattaforma web da anni. Questi aggiornamenti miglioreranno la compatibilità del browser nell'ambito dell'iniziativa #Compat2021 e miglioreranno l'utilizzo delle tabelle sulla piattaforma web in generale. Alcuni dei problemi più speciali sono position: sticky nelle righe, la geometria dei sottopixel e il corretto compressione dei bordi.

L'impegno TablesNG

TablesNG è un'iniziativa pluriennale guidata dallo sviluppatore di Chrome Aleks Totic, che mira a riprogettare completamente il modo in cui le tabelle vengono visualizzate sul web. Le tabelle sono una particolare area di attrito nello sviluppo web, in parte a causa della loro cronologia.

Parti di una tabella

Le tabelle sono state aggiunte al codice HTML nel 1994 e utilizzate per molti anni come metodo principale per creare layout di pagina complessi. Sono ancora presenti sul web, anche se l'uso moderno è in genere per mostrare dati tabulari. Tuttavia, ci sono grandi differenze nel comportamento delle tabelle tra i browser, molti dei quali sono dovuti a una specifica incompleta delle tabelle e all'assenza di dettagli. Le tabelle sono state implementate nei browser prima di molte funzionalità CSS: modalità di scrittura ortogonali, position:relative, box-sizing, container flexbox e altro ancora. Pertanto, il supporto per molte di queste funzionalità non era coerente.

Screenshot del sito web di Space Jam
L'innovativo layout della tabella presente sul sito web di Space Jam, tramite Shannon Draper.

La nuova specifica, CSS Table Module Level 3, è stata scritta dopo il reimplementazione delle tabelle da parte di Edge nel 2018. TablesNG è un progetto di riprogettazione dell'architettura che punta non solo a seguire queste nuove specifiche, ma anche a correggere molte delle incoerenze nelle tabelle lungo il percorso. Alcune delle modifiche più visibili sono:

  • Attivazione del posizionamento fisso nelle righe per le tabelle lunghe che scorrono.
  • Correzione dell'allineamento con la geometria di sottopixel e i bordi della tabella.
  • È stata migliorata la colorazione di sfondi e bordi.

position: sticky nelle righe

Una delle domande più frequenti e più frustranti in relazione allo stile delle tabelle in passato è stata la mancanza di supporto per position: sticky nelle righe. Questa funzionalità consente di mantenere l'intestazione di una tabella sulla pagina mentre scorri e di fornire contesto a tabelle di dati lunghe. Quando fai scorrere l'intestazione per nasconderla e vedi una tabella piena di numeri, è facile dimenticare il significato di questi numeri.

L'intestazione della tabella non rimane in questa posizione fissa, nonostante position: sticky sia stato applicato a <thead>.

Il motivo per cui esiste da così tempo questo bug è perché position: sticky è stato specificato ben dopo l'uscita delle tabelle HTML. Prima di questa correzione, le intestazioni con position: sticky previste venivano solo convertite in position: static, mentre ora puoi utilizzare position: sticky in qualsiasi punto delle tabelle: nelle intestazioni (<thead> etichette) o nelle etichette.

L'intestazione della tabella ha un posizionamento fisso in Chromium 91 e versioni successive. Vedi Demo su codepen.

Pittura del bordo e dello sfondo migliorate

Uno dei bugs delle tabelle meno recenti risale a settembre 2008. È stata presentata quasi non appena Chrome è stato rilasciato e non è mai stato risolto a causa della vecchia architettura delle tabelle. Il problema riguarda la pittura delle tabelle e i bordi compressi.

Il modo in cui le tabelle vengono visualizzate, nell'ordine di z-index, è: celle > righe > sezioni > tabelle. Dopodiché vengono colorate in base all'ordine in cui appaiono nel DOM (Document Object Model), anche se le celle stesse sono in ordine DOM inverso, in cui la prima cella della tabella è la più in alto.

ordine z-index delle tabelle

Quindi il problema qui è che i bordi appartengono alla tabella, non alla cella, nel vecchio modo in cui le tabelle erano dipinti. I bordi compressi vengono dipinti quando la tabella colora il primo piano. Ciò significa che una singola cella di tabella non può avere più bordi:

rendering della tabella corretto e non corretto
A sinistra: rendering della tabella non corretto prima di TablesNG. A destra: visualizzazione corretta dei bordi di una tabella in TablesNG.

Nell'esempio precedente, puoi vedere che la cella blu più a sinistra veniva visualizzata erroneamente sopra la cella in basso a destra arancione perché non poteva avere più bordi. Nell'implementazione riprogettata, il problema è stato risolto e la cella di confine arancione viene applicata correttamente su quella blu, in modo che il secondo spazio della tabella abbia linee di bordo blu e arancione.

Questo bug è stato corretto in Chromium e Firefox.

Geometria dei pixel secondari (allineamento della tabella)

L'allineamento di pixel nelle tabelle è un altro problema di interoperabilità che è stato risolto con TablesNG. In precedenza, il motore precedente arrotondava sempre i valori grafici al pixel. In questo modo, quando aumenti e diminuisci lo zoom della pagina, gli elementi cambiavano, con problemi di allineamento. TablesNG risolve questi problemi di allineamento.

Riprogettare l'architettura del web

Il team di Chrome non solo ha introdotto nuove funzionalità per rendere più affidabili le funzionalità di creazione di siti web, ma si è anche impegnato a fondo per migliorare le API esistenti e la loro compatibilità. Infatti TablesNG è solo uno dei tanti progetti di riprogettazione che questo team ha intrapreso negli ultimi otto anni. Altri, anche se non tutti i progetti, includono:

  • LayoutNG: una riscrittura da zero di tutti gli algoritmi di layout, per un'affidabilità notevolmente superiore e prestazioni più prevedibili.
  • BlinkNG: una pulizia sistematica e un refactoring del motore di rendering Blink in fasi della pipeline separate in modo pulito. Ciò consente una migliore memorizzazione nella cache, maggiore affidabilità e funzionalità di rientro/rendering ritardato, come visibilità dei contenuti e query nei container.
  • GPU Raster Everywhere: un impegno a lungo termine per implementare la rasterizzazione GPU su tutte le piattaforme, ove possibile.
  • Scorrimento in thread e animazioni: uno sforzo a lungo termine per spostare tutte le animazioni di scorrimento e non che provocano il layout nel thread del compositor.

Non perderti gli altri aggiornamenti su questi miglioramenti e altro ancora.