---
url: 'https://simonerescio.it/en/2015/01/css-table-webkit-blink-missing-pixel-with-width-100'
title: 'CSS table, WebKit, Blink and the missing pixel with width 100%'
author:
  name: Simone Rescio
  url: 'https://simonerescio.it/en/about-me/'
date: '2015-01-14T23:52:58+01:00'
modified: '2026-04-22T23:32:17+02:00'
type: post
summary: 'CSS tables and the 1px missing pixel bug: on WebKit and Blink-based browsers (Chrome, Safari, Opera), elements with display:table and width:100% show a 1px flicker during parent resize. Bug analysis and two workarounds.'
categories:
  - CSS
tags:
  - blink
  - bug
  - bugzilla
  - CSS
  - css table
  - WebKit
image: 'https://simonerescio.it/wp-content/uploads/2015/01/ruler-gun.jpg'
published: true
---

# CSS table, WebKit, Blink and the missing pixel with width 100%

Old saying:

> If you never tried to center vertically a text, you know nothing about CSS

**CSS tables** are the main instrument that browsers, since IE8 included and above, make available to perform basic typographical operations such as center a text vertically inside of a container without knowing the height of the container nor the bulk of the text in terms of font size and number of lines, without them the property `vertical-align:middle` is pretty much useless.

If you need a refresher on CSS tables for mobile layouts, see [CSS table, basic structure for a typical mobile app layout](https://simonerescio.it/en/2014/06/css-table-structure-typical-mobile-app-layout).

A typical example is the caption within an image, with a CSS table it’s possible to allow the text to stay centered no matter if it’s a single line or multiple lines, as long as its height is less than its container it will remain centered, otherwise the container will grow in height to accommodate the exceeding content.

In this case the effect you want to achieve is that the container caption covers in width the parent container, reason why we apply the `width:100%` property, and as long as the size of the parent container remains fixed everything works as planned.

- [1. 1px bug](#1px-bug)
- [2. Workaround](#workaround)
- [3. Bugzillas](#bugzillas)

## 1px bug

Problems arise on ***WebKit*** and ***Blink*** based browsers, meaning on all desktop and mobile versions of Chrome, Safari and Opera.  

If the size of the parent container is itself variable, meaning set using a percentage unit, you will notice a strange effect: resizing the parent, the child with `display:table` and `width:100% `will not overlap perfectly its father at all stages of the resizing process, you will notice instead a sort of **flicker of 1px**, on the right or left side of the element depending on the type of `position` and `float` applied.

In the case of the previous demo, adding an animation helps to grasp better the issue, if the element is in `position:relative` and with `float:right` the flickering can be observed on the left side, also it becomes clear how the text “tremble” during the animation due to the size of the box not being calculated correctly:

The bug is also illustrated in the following GIF while occurring on the right side, highlighted in red are the elements that use `display` values of the `table` type, if the element is in `position:absolute` the flickering will occur always on the right side of the element even if you apply a `float:right`, behavior observed in Chrome Mac Version 39.0.2171.95 (64-bit):

 

[![GIF showing 1px flicker on the right side of CSS table elements during parent resize](https://simonerescio.it/wp-content/uploads/2015/01/css-table-width.gif)](https://simonerescio.it/en/2015/01/css-table-webkit-blink-missing-pixel-with-width-100/css-table-width-2)

The previous GIF is based on the following demo, where all types of `display` values are tested, using 100% width and animation on the parent container of all elements, here can be observed how all the elements with `display` value belonging to the `table` category do not respect the `width:100%` property, but when the father shrinks enough to force them to fit they all exhibit the same behavior of the values `table` and `inline-table`:

## Workaround

There are two possible ~~porkaround~~ workarounds for this bug which should be assessed according to the needs of the situation:

- Assign to the container a table-type `display` value as well, so that  by adopting the same algorithm, the width bug is not identifiable.

- Nesting the element with `display:table` inside another element with `display` of any other type that can properly apply the `width:100%` property.

The first method avoids introducing additional HTML and “solves” the problem with a single CSS declaration, however, if the element is for example part of a column with other elements which all have the same width this is going to move the bug, rather than solve it, yet this allows to use the `min-height` property directly on the `table` element so that the height remains dynamic, allowing for better management of borderline cases.

The second method has the undesirable side effect of adding an additional HTML element and moreover it will require to apply an explicit value to the `table`‘s height so that the container will expand to fill it vertically thus allowing to center its contents, however, this entails that if the content exceeds the available vertical space the outer container will not expand to accommodate the content and the directives of the `overflow` property will kick in.

[![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/en/2015/01/css-table-webkit-blink-missing-pixel-with-width-100/you-gotta-do-what-you-gotta-do-2)This bug is visible only when the `table` element that is resized exposes a background color or border, so if you do not use these visual attributes you can just ignore it. Both solutions aren’t optimal for each single case, which means that you will have to evaluate each time which one is the lesser evil, it is not beautiful but “*You gotta do what you gotta do*“.

**Update (2026):** this issue affected WebKit/Blink-based browsers from the mid-2010s; it is no longer reproducible in current Chrome, Safari, and Opera. For modern layouts prefer `flex` or `grid`, while CSS tables remain useful wherever you still need the typographic behaviors described in this article.

## Bugzillas

Hoping that this annoying bug will be eventually solved, I opened an issue on bugzilla respectively for [WebKit](https://bugs.webkit.org/show_bug.cgi?id=140371) and [Blink](https://issues.chromium.org/issues/40499694), if the *issues* will be enhanced by further reports the probabilities that someone will take charge and resolve them once and for all will be higher, hopefully simultaneously (yay for forks!).

 [](https://mastodon.social/share?text=http%3A%2F%2Fsresc.io%2F5TP&title=CSS%20table%2C%20WebKit%2C%20Blink%20and%20the%20missing%20pixel%20with%20width%20100%25)[](https://www.linkedin.com/sharing/share-offsite/?url=http%3A%2F%2Fsresc.io%2F5TP)[](https://simonerescio.it/en/2015/01/css-table-webkit-blink-missing-pixel-with-width-100)[](https://reddit.com/submit?url=http%3A%2F%2Fsresc.io%2F5TP&title=CSS%20table%2C%20WebKit%2C%20Blink%20and%20the%20missing%20pixel%20with%20width%20100%25)[](https://api.whatsapp.com/send?text=CSS%20table%2C%20WebKit%2C%20Blink%20and%20the%20missing%20pixel%20with%20width%20100%25 http%3A%2F%2Fsresc.io%2F5TP)[](https://bsky.app/intent/compose?text=CSS%20table%2C%20WebKit%2C%20Blink%20and%20the%20missing%20pixel%20with%20width%20100%25%20http%3A%2F%2Fsresc.io%2F5TP)[](https://telegram.me/share/url?url=http%3A%2F%2Fsresc.io%2F5TP&text=CSS%20table%2C%20WebKit%2C%20Blink%20and%20the%20missing%20pixel%20with%20width%20100%25)[](https://www.facebook.com/sharer/sharer.php?u=http%3A%2F%2Fsresc.io%2F5TP)

