[css-text] Should browsers apply a minimum width to tabs? #2883
Description
Testcase: https://jfkthame.github.io/test/tab-min-width.html
Relevant spec text from https://drafts.csswg.org/css-text/#white-space-phase-2, step 2:
If the tab size is zero, tabs are not rendered. Otherwise, each tab is rendered as a horizontal shift that lines up the start edge of the next glyph with the next tab stop. Tab stops occur at points that are multiples of the tab size from the block’s starting content edge. The tab size is given by the tab-size property.
This implies that if the current position in the line, when a tab is encountered, is just slightly short of a tab stop -- say, 1px before it, or even 0.1px before it -- the start of the next glyph will be lined up with that tab stop, resulting in an extremely narrow width for the tab.
The testcase shows that Webkit and Blink enforce a minimum advance for the tab, so that if the distance to the next tab stop is less than 0.5ch, they will actually skip that tab stop and move to the next. So the column of "foo"s in the testcase jumps over as soon as the width of the initial span exceeds 7.5ch.
Firefox and Edge, on the other hand, do not enforce any minimum width for the tab, and so the "foo"s don't jump to the right until the span width reaches 8ch.
The Firefox/Edge behavior seems correct per spec; there's nothing in there about skipping a tab stop position if we're within 0.5ch (or any other small-but-nonzero distance) of it. However, I think a reasonable case could be made for the Webkit/Blink behavior.
The current discrepancy can result in real-world webcompat issues, as seen for example in webcompat/web-bugs#17530. Should we file bugs against Blink and Webkit and ask them to change behavior to strictly follow the current spec, or should we amend the spec to match their behavior (and ask Gecko and Edge to change accordingly)?