Chrome-only variability in rendered width of a divider line

Question

I'm creating a multi-format editable date/time widget, and I just noticed how a divider line in one widget looked fatter than the same line other widgets (fatter in the one with the red text):

Here's the CSS for that:

.tbw-dse-divider {
  align-self: stretch;
  background-color: #A6A6A6;
  margin: 0 max(1px, 0.0836em);
  overflow: hidden;
  position: relative;
  white-space: nowrap;
  width: max(1px, 0.0836em);
}

If I tweak this CSS by moving the position of the divider half a pixel with left: 0.5px, that one divider gets thinner, and the others get fatter:

According to the web console, this line is rendered at 2.5px wide. I'm guessing this is some sort of round-off error, where sometimes I get 2 pixels, sometimes I get 3 pixels.

Neither Firefox nor Safari have this problem, and the divider's appearance is always consistent. The screenshot is from a high-res screen, so it should be easily possible to render half of a px cleanly.

Does anyone know a way to fix this Chrome width-rounding problem?

As rendered by Firefox:

Are the widget the same size in chrome and elsewhere? Does font-size, font-family,letter-spacing render the same or reproduce a similar visual in any of your browsers if reset otherwise? — G-Cyrillus, Jul 14 '21 at 16:44
@G-Cyrillus, other than this width-rounding issue, the widgets look the same on other browers. I'll add a Firefox screenshot to the post. — kshetline, Jul 14 '21 at 16:54
You can pick your own answer as the solution. It will be usefull to the next *you* with a similar issue. — G-Cyrillus, Jul 14 '21 at 19:44

score 1 · Accepted Answer · answered Jul 14 '21 at 17:04

I found an answer by searching the topic of "subpixel rendering". The following silly trick fixes the problem:

.tbw-dse-divider {
  align-self: stretch;
  background-color: #A6A6A6;
  margin: 0 max(1px, 0.0836em);
  overflow: hidden;
  position: relative;
  white-space: nowrap;
  width: max(1px, 0.0836em);
  transform: rotate(-0.0000000001deg);
}

The nearly-0 rotational transform tricks Chrome into doing subpixel rendering that it would otherwise not bother trying to do. Answer found here: Is there a way I can force chrome to do subpixel rendering for a slow translation?

Chrome-only variability in rendered width of a divider line

1 Answers1