--- url: 'https://simonerescio.it/2015/01/css-table-webkit-pixel-mancante-larghezza-100' title: 'CSS table, WebKit, Blink e il pixel mancante a larghezza 100%' author: name: Simone Rescio url: 'https://simonerescio.it/chi-sono/' date: '2015-01-14T23:52:58+01:00' modified: '2026-04-22T23:32:17+02:00' type: post summary: 'CSS table e il bug del pixel mancante: su Chrome, Safari ed Opera (WebKit e Blink), gli elementi con display:table e width:100% mostrano uno sfarfallio di 1px durante il ridimensionamento del contenitore. Analisi del bug e due workaround.' categories: - CSS tags: - baco - blink - bugzilla - CSS - css table - WebKit image: 'https://simonerescio.it/wp-content/uploads/2015/01/ruler-gun.jpg' published: true --- # CSS table, WebKit, Blink e il pixel mancante a larghezza 100% Dice il saggio: > Se non hai mai provato a centrare verticalmente un testo, non sai nulla di CSS Le **CSS table** sono lo strumento principale che i browser, da IE8 compreso in su, ci mettono a disposizione per effettuare operazioni tipografiche fondamentali come *centrare verticalmente un testo* all’interno di un contenitore, senza sapere né l’altezza del contenitore né l’ingombro del testo in termini di grandezza e numero di righe, senza di esse la proprietà `vertical-align:middle` è praticamente carta straccia. Se ti serve un ripasso sulle CSS table per il layout mobile, trovi una guida di base in [CSS table, struttura base per il layout di una tipica app mobile](https://simonerescio.it/2014/06/css-table-struttura-base-layout-tipica-app-mobile). Un tipico esempio è la didascalia all’interno di una immagine, che tramite CSS table si riesce ad impostare in modo che quando il testo è su una singola riga o più righe ma comunque di grandezza inferiore al contenitore resta centrato, altrimenti il contenitore cresce in altezza rispetto al testo stesso. In questo caso l’effetto che si desidera ottenere è che il contenitore della didascalia copra in larghezza il contenitore padre, motivo per cui si applica la proprietà `width:100%`, e fintanto che la dimensione del contenitore padre resta fissa tutto funziona come da programma. - [1. 1px bug](#1px-bug) - [2. Workaround](#workaround) - [3. Bugzillas](#bugzillas) ## 1px bug I problemi sorgono sui browser basati su *WebKit* e* Blink*, ovvero su tutte le versioni desktop e mobile di Chrome, Safari ed Opera. Se la dimensione del contenitore padre è a sua volta variabile, ovvero impostata con un’unità di misura percentuale, si noterà uno strano effetto: ridimensionando l’elemento padre, il figlio con `display` di tipo `table` con larghezza 100% non si sovrapporrà perfettamente al padre in tutti gli stadi del ridimensionamento, si noterà invece una sorta di **sfarfallio di 1px**, sul lato destro o sinistro dell’elemento a seconda del tipo di `position` e `float` applicato. Nel caso della demo precedente, aggiungendo un’animazione si coglie meglio il problema, se l’elemento è in `position:relative` e si applica  un `float:right` si può osservare lo sfarfallamento sul lato sinistro, si nota inoltre come il testo “tremi” durante l’animazione a causa della dimensione del box che non viene calcolata correttamente: Il bug è illustrato anche nella seguente GIF mentre si manifesta sul lato destro, in rosso sono evidenziati gli elementi a cui sono applicati valori `display` di tipo `table`,  se l’elemento è in `position:absolute` il flickering avverrà sempre sul lato destro dell’elemento anche  se si applica un `float:right`, comportamento osservato in Chrome Mac Versione 39.0.2171.95 (64-bit): [![GIF che mostra lo sfarfallio di 1px sul bordo destro di elementi con display table](https://simonerescio.it/wp-content/uploads/2015/01/css-table-width.gif)](https://simonerescio.it/2015/01/css-table-webkit-pixel-mancante-larghezza-100/css-table-width/) Di seguito la demo da cui è tratta la GIF precedente, in cui sono testati tutti i tipi di `display`, applicando larghezza 100% ed un’animazione al contenitore padre di tutti gli elementi, si nota anche come tutti gli elementi con `display` appartenente alla categoria `table` ma che non osservano affatto la proprietà `width:100%`, quando il padre si restringe abbastanza da costringerli ad adattarsi in larghezza manifestano lo stesso comportamento dei valori `table` e `inline-table`: ## Workaround Ci sono due possibili ~~porkaround~~ workaround per questo bug che vanno valutati in base alle necessità contingenti: - Assegnare anche al contenitore il `display` di tipo `table`, così che adottando lo stesso algoritmo di calcolo della larghezza il bug non sia individuabile. - Annidare l’elemento con `display:table` dentro un altro elemento con `display` di qualunque altro tipo che può osservare correttamente la proprietà `width:100%`. Il primo metodo evita di introdurre HTML aggiuntivo e “risolve” con una sola dichiarazione CSS in più, tuttavia se l’elemento in questione fa parte ad esempio di una colonna con altri elementi che hanno tutti la stessa larghezza rischia di spostare il bug piuttosto che risolverlo, permette tuttavia di applicare la proprietà `min-height` direttamente sull’elemento `table` in modo tale che l’altezza resti dinamica, permettendo una migliore gestione dei casi limite. Il secondo metodo ha l’effetto indesiderato di aggiungere un ulteriore elemento HTML “superfluo”, ed in più sarà necessario applicargli una `height` esplicita affinché il contenitore `table` si espanda in altezza al 100% permettendo quindi di centrare il suo contenuto, tuttavia questo comporta che qualora il contenuto ecceda lo spazio disponibile il contenitore esterno non si espanderà per accoglierlo ed entreranno in gioco le direttive della proprietà `overflow`. [![You gotta do what you gotta do](https://simonerescio.it/wp-content/uploads/2015/01/you-gotta-do-what-you-gotta-do-e1488670781933-300x228.jpg)](https://simonerescio.it/2015/01/css-table-webkit-pixel-mancante-larghezza-100/you-gotta-do-what-you-gotta-do)Questo bug si manifesta all’occhio solo nei casi in cui l’elemento `table` che viene ridimensionato espone un colore di sfondo o dei bordi, quindi se non si usano questi attributi visivi si può fare a meno di applicare una fix. Nessuna delle due soluzioni è ottimale per ogni casistica, andrà quindi valutato il male minore caso per caso, non è bellissimo ma “*Bisogna fare quello che bisogna fare*“. **Aggiornamento (2026):** questo bug interessava le versioni di Chrome, Safari ed Opera basate su WebKit/Blink degli anni 2010; nei browser attuali non è più riproducibile. Per layout moderni preferisci `flex` o `grid`, mentre le CSS table restano utili dove servono ancora i comportamenti tipografici descritti nell’articolo. ## Bugzillas Nella speranza che questo baco fastidioso venga prima o poi risolto ho aperto un issue su bugzilla rispettivamente per [WebKit](https://bugs.webkit.org/show_bug.cgi?id=140371) e [Blink](https://issues.chromium.org/issues/40499694), se gli *issue* verranno arricchiti da ulteriori segnalazioni la probabilità che qualcuno li prenda in carico e li risolva una volta per tutte sarà più alta, si spera contemporaneamente (W i fork!). [](https://mastodon.social/share?text=http%3A%2F%2Fsresc.io%2F5TM&title=CSS%20table%2C%20WebKit%2C%20Blink%20e%20il%20pixel%20mancante%20a%20larghezza%20100%25)[](https://www.linkedin.com/sharing/share-offsite/?url=http%3A%2F%2Fsresc.io%2F5TM)[](https://simonerescio.it/2015/01/css-table-webkit-pixel-mancante-larghezza-100)[](https://reddit.com/submit?url=http%3A%2F%2Fsresc.io%2F5TM&title=CSS%20table%2C%20WebKit%2C%20Blink%20e%20il%20pixel%20mancante%20a%20larghezza%20100%25)[](https://api.whatsapp.com/send?text=CSS%20table%2C%20WebKit%2C%20Blink%20e%20il%20pixel%20mancante%20a%20larghezza%20100%25 http%3A%2F%2Fsresc.io%2F5TM)[](https://bsky.app/intent/compose?text=CSS%20table%2C%20WebKit%2C%20Blink%20e%20il%20pixel%20mancante%20a%20larghezza%20100%25%20http%3A%2F%2Fsresc.io%2F5TM)[](https://telegram.me/share/url?url=http%3A%2F%2Fsresc.io%2F5TM&text=CSS%20table%2C%20WebKit%2C%20Blink%20e%20il%20pixel%20mancante%20a%20larghezza%20100%25)[](https://www.facebook.com/sharer/sharer.php?u=http%3A%2F%2Fsresc.io%2F5TM)