Able to reproduce the issue on windows 7, Ubuntu 14.04 and Mac 10.12.4 using chrome version 58.0.3029.96 and canary 60.0.3087.0.
This is non regression issue as the issue seen from M30 old builds.
Marking it as Untriaged to get more inputs from dev team.

Thanks,

We have a similar problem with Windows 10. The combination of Windows Zoom and Chrome Zoom is changing the column widths. For example, when Windows zoom at 100% and Chrome zoom at 125%, some columns (not all of them) start to be off by one pixel. Same for Windows at 125% and Chrome at 100%, 110%,and 125%. We think it's the same problem as this one. The width is changed by the zooming percentage. There is no update since May 3. Is there any progress on fixing this bug? Thank you.

Table cells are aligned to device pixels and round independently of each other to ensure that two or more cells given the same width are rendered at the same width. This is different from most other layout types in blink.

When zoom is applied the 25% cells (in this case) all round up. As does the 100% one. This results in the combination of the four 25% cells being 3px wider than the 100% one. This is by design and working as intended as otherwise the width of the 25% cells would be inconsistent.

The easiest way to avoid this is to have both rows be in the same table and use cellspan. That way the cells are guaranteed to align.

I disagree with your conclusion, because the width of the 25% cells over the whole table always is "inconsistent", and ever will be, since you always have a remainder when dividing the width of the table by the number of cells.

The question only is where to put this remainder, and Chrome obviously decides that the remainder should be put onto the last cells, instead of spreading it out evenly over the whole width of the table. With more and even smaller columns, the eye may start to notice this even without my second "ruler table" for comparison.

Please note that this affects your proposed tables with colspan as well, Chrome is the only browser where rendering differs notably depending on whether the small columns are 25px wide or the spanned columns are 100px wide. (See attached index.html)

Deleted: index.htm 6.6 KB

index.htm 6.6 KB View Download

Please reconsider fixing this bug. Other browsers work as expected, visually it is clear that layout is broken. 

Large tables with spans are essential for working with larger amount of data in browser. Complicating DOM to work around this bug, lowers the performance.

Here is how it looks at 25% zoom out. 

Deleted: aaa.png 988 bytes

	aaa.png 988 bytes View Download

the above screenshot is from Chrome 63-beta on Windows 10.

Hello Konrad,

I fear that your problem is entirely different. In your case, the issue is that on 25%, the cells are too narrow to fully render the text, and Chrome decides (correctly) to increase the cell width until the text fits into the cell. I may be wrong, but this does not look like the described subpixel issue. Please check whether the style text-overflow:ellipsis or text-overflow:clip on all cells fixes your table size.

text-overflow:ellipsis or clip on each TD does not fix the issue.
However, I agree that it may be a different issue.

I'm more interested in proper alignment of lower level cell borders with higher level borders, than in fixing the extreme case like this. I was just trying to make the problems more evident.