- From: Javier Fernandez Garcia-Boente via GitHub <sysbot+gh@w3.org>
- Date: Tue, 02 Mar 2021 11:54:02 +0000
- To: public-css-archive@w3.org
javifernandez has just created a new issue for https://github.com/w3c/csswg-drafts:
== [css-text] Tabs and the end of the line with pre-wrap and break-word ==
I'm not sure the spec covers this scenario, where a sequence of tab preserved spaces overflow, with a combination of CSS properties that allow wrapping (allowing them to hang) and break-word (introducing additional breaking opportunities).
Lets consider the following example:
```
<!DOCTYPE html>
<style>
#t {
font: 30px/1 Ahem;
white-space: pre-wrap;
overflow-wrap: break-word;
width: 15px;
border: 2px solid red;
}
span { background: blue; }
</style>
<p>Examples with Tab</p>
<div id=t><span>		</span><span>X</span></div>
<br>
<div id=t><span>X</span><span>		</span></div>
<p>Examples with Spaces</p>
<div id=t><span>  </span><span>X</span></div>
<br>
<div id=t><span>X</span><span>  </span></div>
```
The box has a width that causes every character to overflow (the case would be similar with a width that is at least 1ch width, since tabs wouldn't fit either, but I wanted to show the behavior when using regular white spaces as well).
The spec [states](https://drafts.csswg.org/css-text-3/#white-space-processing) clearly that a sequence at the end of the line could hang, honoring the 'white-space: pre-wrap' property.
> 4. If there remains any sequence of [white space](https://drafts.csswg.org/css-text-3/#white-space), and/or other space separators, at the end of a line (after bidi reordering [CSS-WRITING-MODES-3]):
> [ ...]
> * If white-space is set to pre-wrap, the UA must (unconditionally) hang this sequence, unless the sequence is followed by a forced line break, in which case it must conditionally hang the sequence is instead. It may also visually collapse the character advance widths of any that would otherwise overflow.
As far as I understand the spec, 'white space' implies 0020 and tabs characters, is it's stated in the link used in the above statement.
However, when using the 'overflow-wrap: break-word' property, we are introducing [additional breaking opportunities](https://drafts.csswg.org/css-text-3/#overflow-wrap-property), so that some of the previously defined as 'preserved spaces' could be broken indeed.
`An otherwise unbreakable sequence of characters may be broken at an arbitrary point if there are no otherwise-acceptable break points in the line. `
Additionally, going back to the test case I defined at the beginning, I assume that both, leading and trailing sequences of space should be handled in the same way in this case, because I believe both can be treated as 'trailing spaces' (please, correct me if I'm wrong).
This is how Firefox and Chrome render the mentioned test case, showing clearly an interoperability issue:
<table>
<tr><td><b>Chrome 90</b></td><td><b>Firefox 85</b></td></tr>
<tr><td><img src="https://user-images.githubusercontent.com/2230241/109644347-a83def80-7b55-11eb-8d2b-a6ba430eba36.jpg"/></td><td><img src="https://user-images.githubusercontent.com/2230241/109644365-ad9b3a00-7b55-11eb-994d-35508004c5a8.jpg"/></td></tr>
</table>
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6062 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 2 March 2021 11:54:04 UTC