[css-text] pre-wrap and tabs at the end of the line

[frivoal]

The spec doesn't say what happens to preserved tabs at the end of the line in the modes where wrapping is allowed (pre-wrap and break-spaces).

• For pre-wrap, based on testing, they should be handled like preserved spaces in the same situation: become part of the unbreakable sequence of tabs and spaces (and ideographic spaces) that hangs and that has a wrapping opportunity at the end of it.

• for break-spaces, the value is new enough that interop data isn't very meaningful, but I'd suggest being consistent and also doing the same thing as preserved spaces: cannot hang, wrap opportunity after every preserved tab, plus a wrap opportunity between the last letter of a word and the tab that imediately follows it if line-break is anywhere.

[css-meeting-bot]

The CSS Working Group just discussed Pre-wrap and tabs.

The full IRC log of that discussion

<fantasai> Topic: Pre-wrap and tabs
<fantasai> github: https://github.com//issues/3869
<fantasai> florian: Also came up writing tests ...
<fantasai> florian: We say what happens to spaces at the end of the line. We don't say what happens to tabs.
<fantasai> florian: I suppose the same thing happens, but spec doesn't say
<fantasai> florian: Spec describes tabs rendered as a shift, not a visible thing
<fantasai> fantasai: certainly if spaces after the tab, should be rendered as a shift
<fantasai> fantasai: but at the end of the line, wouldn't be surprised if they disappeared
<fantasai> ...
<fantasai> fantasai: definitely treat the same as spaces for break-spaces
<fantasai> fantasai: not so sure for others
<fantasai> myles: I agree with Florian, treat it like spaces.
<fantasai> myles: it's a Unicode character just like any other
<fantasai> fantasai: Its size changes depending on its position in the line
<fantasai> florian: Spec allows UA to compress their width to zero at the end of the line, could do that with tabs also
<fantasai> fantasai: That won't be allowed in L4 though
<fantasai> fantasai: ... wrt myles's point about font shaping, characters change shape depending on context
<fantasai> fantasai: But not depending on their position within the line, which is what tabs do
<fantasai> ...
<fantasai> fantasai: I'm not really sure what should happen, but I lean towards tabs not being allowed to hang
<fantasai> fantasai: partly for that, partly because they are quite large = 8 spaces by default
<fantasai> florian: But you want your caret to be visible if you put it after the tab
<fantasai> AmeliaBR: Tabs at the end of the line are rare. Also if you want to edit, you want to be able to see them.
<fantasai> myles: don't want too many special cases
<fantasai> plinss: Tabs are used for delimiting things. Shouldn't disappear.
<fantasai> fantasai: who's saying anyting about disappearing? I'm saying they shouldn't hang. Doesn't mean they disappear
<fantasai> fantasai: Treat it just like a visible character, it causes text to wrap to the next line.
<fantasai> fantasai: Hanging allows things to overflow even when there are sufficient wrapping opportunities in the line ot not overflow
<fantasai> myles: tabs are more like spaces than visible characters
<fantasai> florian: like spaces or nbsp?
<fantasai> AmeliaBR: Maybe continue this discussion in the issue, write out the options and add examples of how that would work for use cases e.g. editing text, viewing tab-delimited data, etc.
<fantasai> ACTION Florian write up options
<trackbot> Created ACTION-878 - Write up options [on Florian Rivoal - due 2019-05-15].

[fantasai]

So it seems like no one is arguing for anything other than "can't hang, wraps like a fat space" for break-spaces, and the open question is on what to do in the normal pre-wrap case...

• We didn't really discuss much whether a mixed sequence of tabs and spaces should be breakable or not, but in any case implementations don't break in such sequences so we should go with that.
• We're not agreed on whether tabs are allowed to “hang” at the end of the line or not. (Hanging means they aren't measured when we measure the size of text on the line for the purposes of line breaking, sizing, alignment, or justification.)

An additional note is that the size of a tab depends on where in the line it appears -- not on adjacent context, but on actual position.

There are not many use cases for trailing tab characters; one brought up was TSV files, where trailing tabs are significant and denote separate fields.

[css-meeting-bot]

The CSS Working Group just discussed pre-wrap and tabs at the end of the line.

The full IRC log of that discussion

<dael> Topic: pre-wrap and tabs at the end of the line
<dael> github: https://github.com//issues/3869
<dael> fantasai: I summerized issue. No agreement on if tabs can hang at end of line. ONly use case is tab separated value files. No clear direction
<dael> florian: I was actioned to give examples and haven't. Agree with fantasai we agree on break spaces, but pre-wrap is tricky.
<dael> Rossen_: Remove from agenda until have test cases?
<dael> florian: May also want to do break-spaces
<dael> Rossen_: Let's look at everything at once. Otherwise you might find some new evidence and we need to re-open
<dael> Rossen_: I'll remove agenda+

[frivoal]

I'll go with the assumption @fantasai was making: no breaking between tabs (or spaces) in a sequence of them. So the remaining question seems to be: hang or no hang. Here's an example:

Let's assume a Tab Separated Value file like this:

<style>.tsv { white-space: pre-wrap; }</style>
<pre class=tsv>Field1&#9;Field2&#9;Field3&#9;Field4
A&#9;B&#9;&#9;
1&#9;2&#9;3&#9;4
</pre>

It would render something like that ("_" marks tab-induced shifts)

Field1__Field2__Field3__Field4
A_______B_______________
1_______2_______3_______4

Now, let's say we set pre { width: 16ch; }.

If tabs hang, it looks like this:

|Field1__Field2__|
|Field3__Field4  |
|A_______B_______|________
|1_______2_______|
|3_______4       |

If they don't:

|Field1__Field2__|
|Field3__Field4  |
|A_______        |
|B_______________|
|1_______2_______|
|3_______4       |

And for what it's worth, if we did allow wrapping between tabs and disallow hanging, we'd get this:

|Field1__Field2__|
|Field3__Field4  |
|A_______B_______|
|________        |
|1_______2_______|
|3_______4       |

Here's a live demo of that example:
https://jsbin.com/regoquzame/edit?html,css,output

• Firefox does behavior 2 (don't hang)
• Safari and Chrome do behavior 1 (do hang)

[css-meeting-bot]

The CSS Working Group just discussed pre-wrap and tabs at the end of the line, and agreed to the following:

• RESOLVED: Tabs do not hang and you can break between for whitespace: break-spaces
• RESOLVED: For white-space:pre-wrap tabs hang like spaces do

The full IRC log of that discussion

<dael> Topic: pre-wrap and tabs at the end of the line
<dael> github: https://github.com//issues/3869#issuecomment-509811620
<dael> astearns: florian added example
<dael> florian: 2 parts to the discussion. one is hardly discussed and non-controversial. Other was and needed example
<dael> florian: The hardly discussed is just like spaces tabs do not hang and you can break between. Mentioned in issue and no one pushed back.
<dael> florian: I'd like to resolve on that before going to whitespace prewrap
<dael> astearns: Treat tabs the same as issues for this?
<fantasai> for break-spaces, right?
<dael> florian: They can't hang and you can wrap between two consecutive tabs
<dael> astearns: Tabs do not hang and you can break between for whitespace: break spaces
<dael> astearns: Objections?
<fantasai> s/break spaces/break-spaces/
<dael> RESOLVED: Tabs do not hang and you can break between for whitespace: break-spaces
<fantasai> s/whitespace/white-space/
<dael> florian: Now what happens with tabs at end of line with whitespace-prewrap
<dael> florian: Example in document with line empty with tabs at end. What happens if line is too short?
<dael> florian: First is what line is long enough, second is when tab hangs.
<dael> florian: If you disallow hanging and disallow breaking between tabs you get second rendoring. 3rd is disallow hanging but allow breaking between tabs. No one does 3rd, browsers are split between first 2.
<dael> florian: I don't have a strong preference. Weak for option 3 which no one does. But we should try and align on something. Would want to hear if anyone has preference.
<dael> florian: Questions on example? Thoughts on why one is preferable?
<dael> astearns: I don't have much of a preference. Not sure the 3rd is preferable either
<dael> astearns: I don't know why you have weak preference for that
<dael> dbaron: Drawing in example assumes tab stop lines up with end of container.
<dael> florian: I could be a different length, that's correct. I have a line length of 16 in this example. If you did 17 for example line breaking position wouldn't change in any example but you'd have empty space at end of it.
<dael> fantasai: Only difference visually is container is slight wider, but otherwise render same
<dael> dbaron: Complexity with not line up is you would also have to decide if can break in middle of tab
<dael> florian: I assumed you could not, but fair enough. it renders as a shift not a character.
<dael> dbaron: You'd have to decide if you have tab stop at beginning/end of line. If you don't you can break in middle of tab. If you don't have tab stop and your next position is early in next line but not start; I guess it doesn't matter if tab is on first line or part on each line
<dael> fantasai: Tab stop is at beginning of line, but not end of line unless lines up with a multiple of 8 spaces from start of the line
<dael> florian: If we don't have a use case driven preference we can ask the web author folks to fish for one. We have split between browsers now. We can ask who is easier to change.
<dael> florian: Going by use case would be better. Haven't ID'ed any. Should we draw in rachelandrew or jensimmons ?
<dael> dbaron: THis feel obsure to me.
<dael> florian: it does
<dael> astearns: Could resolve on behavior 1 since we have 2 engines doing it
<dael> florian: Yeah...not particular reason to think behavior 1 is terrible so I'm okay with that. It is similar to what happens to spaces in white-space:pre-wrap. That implies FF has to change.
<dael> dbaron: I think consistancy with spaces is reasonable thing. I don't have strong opinions.
<dael> florian: Suspect any impl difficulty?
<dael> dbaron: Hard to say
<dael> astearns: Main difficulty is reason to make the change. I could just be a bug in FF forever
<tantek> is there any way to apply the principle of least surprise here?
<tantek> all other things being equal?
<dael> myles_: Engines have special case for tabs. IT'll be a slightly smaller or larger special case then it would have been. Picking an option is more important then which
<dael> florian: And as to the point about no rush to fix I think this will be low in priority, but there will eventually be a lump of bugs to fix and this will be in.
<dael> astearns: tantek asked in IRC: [reads]. One of the problems is no one has strong opinion on actual expectation
<dael> florian: Being consistent with spaces goes slightly to least surprise. If you know one you know the other
<dael> astearns: Sounds like we are driving toward a preference for the first option since consistent with spaces
<dael> florian: Right, the tabs hang
<dael> astearns: In which?
<dael> astearns: Prop: for white-space:pre-wrap tabs hang like spaces do
<dael> astearns: Objections?
<tantek> that seems reasonable and less noisy (random tabs/ws at end of line won't change layout)
<dael> RESOLVED: For white-space:pre-wrap tabs hang like spaces do

[frivoal]

tests here: web-platform-tests/wpt#17957