I suspect there is indeed an issue with the renderer here; I’m able to reproduce the issue. That said, I don’t think it’s due (exclusively) to the collapsed borders. We start to get a clearer understanding of the issue when we crank up the thickness of the borders.
Here’s the code I’m using below for tests:
CSS:
body > table:first-child {
border-collapse: collapse;
}
td {
border-left: 10px solid red;
border-right: 10px solid green;
border-top: 10px solid orange;
border-bottom: 10px solid pink;
}
table {
display: inline-table;
vertical-align: top;
}
HTML:
<table class="first-table">
<caption>Collapsed</caption>
<tr><td><input /></td></tr>
</table>
<table class="second-table">
<caption>Not Collapsed</caption>
<tr><td><input /></td></tr>
</table>
JavaScript:
document.addEventListener("input", ({ target }) => {
const result = target.value && target.value.length <= 2;
target.style.marginBottom = result ? "3em" : "0em";
});
By default, have a look at how the borders are arranged for both tables.
Brave:
Edge:
Chrome:
Chrome is clearly doing something different with the table. But since Edge and Brave make no major changes to this part of the Chromium source, I suspect this different is due to experimental field trials being enabled in Chrome for particular (or all) users. You can see which variations are enabled for your instance of Chrome by visiting chrome://version.
When you something that changes the dimensions of the table, the renderer tries to intelligently repaint that section of the viewport. Unfortunately, it fails to do so as expected. We wind up with clear artifacts from the original layout:
Note the original left-border (red) remaining above. We can force a repaint by opening the developer tools (right-click, select Inspect Element), and this appears to fix things:
Of course, once we remove the input, causing the layout to be repainted, a new set of artifacts appear:
These types of rendering bugs are pesky, and appear from time to time. Google may already have a solution in place in Chromium, and are testing it out on users before turning it on by default for all users (including those who inherit the fix via Edge and Brave).
In the meantime, you can help the renderer by performing actions which force a repaint. One example is a non-discernable animation on the element itself. For example:
body > table:first-child {
border-collapse: collapse;
animation: rock 2s infinite;
}
@keyframes rock {
to { transform: translateX(0px) }
}
This animation causes the browser to constantly track the element, and make sure that it’s painted properly. Not a great solution, but better than pesky artifacts.
I hope this helps for now; I do hope to see this issue resolved natively in a future build.
