[css-text] Should browsers apply a minimum width to tabs?

[jfkthame]

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 https://github.com/webcompat/web-bugs/issues/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)?

[heycam]

Previous discussion of tab-size: 0 was in #460. (It may be that the web compat issues mean we should revisit that.)

[jfkthame]

Previous discussion of tab-size: 0 was in #460

This isn't about whether the tab-size property should be allowed to be zero, but whether individual tabs should be allowed to shrink to almost-zero if the current position happens to be very close to a tab stop, or should a minimum visual separation be maintained.

(See the testcase, where tab-size is left at its initial value.)

[kojiishi]

@jfkthame's observation is correct--when we've got a bug saying Gecko renders a tab but it's invisible in Blink (crbug/635717), I chose to use half-a-space-width.

I agree that defining the minimum tab width is good for better interoperability. On the other hand, no matter what we define the minimum tab width, matching tab positions seems hard. Any ideas to solve or mitigate this?

[frivoal]

setting the minimum to one space would be ideal, as it would do "the right thing" in the monospaced case, and would do something close for non mono-spaced fonts.

However, there often are little approximations when rounding, meaning exactly 1 space might cause accidental pushing to the next tab stop, so maybe we should use something slightly smaller than a space. However, I think Koji's suggestion of half a space is too small. Visually, that's really narrow, and rounding approximations aside, I don't think people who use a tab want a gap that's much smaller than a space.

Maybe 3/4 of a space ?

[frivoal]

sorry, I misread. In a proportional font, 0.5ch is much broader than 0.5 space characters, which is what I thought you were talking about, and it will still do the right thing in a monospace font. I support that as a minimum.

[frivoal]

Agenda+ to:

• propose a minimum spacing below which we push to the next tab stop
• propose setting that minimum to 0.5ch

[css-meeting-bot]

The CSS Working Group just discussed Applying a min width to rendered tabs.

The full IRC log of that discussion

<gregwhitworth> Topic: Applying a min width to rendered tabs
<astearns> github: https://github.com/w3c/csswg-drafts/issues/2883#issuecomment-421733978
<gregwhitworth> florian: when you have tab stops, if you have a tab - you're supposed to go forward in the line
<gregwhitworth> florian: if your text is coming extremely close to the next tab stop, should there be a minimum size?
<gregwhitworth> florian: Chrome, it jumps to the next one at a specific size and it seems reasonable in a monospaced font
<fantasai> s/Resolved:/RESOLVED:/g
<gregwhitworth> florian: I was thinking about going with 1 space, but maybe we should go smaller than a space
<gregwhitworth> florian: in a proportional font, spaces are already really small - 0.5ch
<gregwhitworth> florian: I'm wanting to take this normative as makes sense
<emilio> astearns: Any comments from the non-chrome team?
<fantasai> +1 from me anyway
<emilio> astearns: proposal is minimum spacing is 0.5ch
<emilio> astearns: objections?
<emilio> astearns: RESOLVED: Make the normative change
<emilio> myles: Should link to the primary font concept
<fantasai> https://www.w3.org/TR/css-values-3/#ch
<emilio> fantasai: it already does via the ch value, though it's not actually the primary font
<emilio> fantasai: it's ch, it's not ambiguous
<emilio> emilio: is it what Blink implements?
<emilio> myles: if the code is the same as WK it's not exactly the same, but we can say ch on the spec
<emilio> astearns: the test for this is not going to test this exactly
<emilio> fantasai: why not?
<emilio> astearns: flaky tests / pixel differences
<emilio> fantasai: fine

[frivoal]

Closed by f4ad04f50e282d2cfff60c2fd5ceeb62d786af4f

[frivoal]

Test: https://github.com/web-platform-tests/wpt/pull/13336