W3C home > Mailing lists > Public > public-css-archive@w3.org > August 2019

Re: [csswg-drafts] [css-text][css-sizing] When to/not to include preserved trailing spaces (#3440)

From: Florian Rivoal via GitHub <sysbot+gh@w3.org>
Date: Thu, 01 Aug 2019 15:34:27 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-517339591-1564673666-sysbot+gh@w3.org>
> the behavior 3 browsers are interoperable today, correct?

No, it is not. Chrome and Firefox are similar, but Safari is different.

None of the existing implementations solve both the alignment/justification use case you brought up when opening this issue and cases like https://crbug.com/453830.

#4095 and #3868 do solve both.

> we once chose to not to hang on center and end

If "we" means the CSSWG, I don't believe we did. At least, the spec as it exists today is not like that, and the resolution in this issue is not like that either.

> I personally like WebKit behavior

Both #4095 (my proposal) and #3868 (the standing resolution) are closer to the Webkit behavior than the current spec text. They both do the same thing as Safari[1] in for spaces at **unforced** breaks. The difference is only about the handling of spaces before **forced** break, which is necessary to handle cases like the one you reported with https://crbug.com/453830. Both #4095 and #3868 solve that case (but current Safari behavior does not).

I think a good way to describe the behavior of my proposal (#4095) would be:
* same as Safari[1] today for spaces before **unforced** breaks
* same as Chrome and Firefox today for spaces before **forced** breaks.

The original resolution (#3868) would be:
* same as Safari[1] today for spaces before **unforced** breaks
* new behavior (no hanging at all) for spaces before **forced** breaks. That's different from all implementations today (web compat concern) and is a worse behavior when editing.

> my point is that adding spaces should change something

I agree. What it changes is a little bit different in different situations, but it changes something:
* If you are adding spaces before a **forced** break (which includes at the end of an element), **and** the spaces fit the line, this will affect alignment
* if you are adding spaces either at before an **unforced** break (whether they fit the line or not), or before a forced break if they don't fit the line, the spaces are inserted[1] (so the caret moves further each time you insert a spce, they affect scrollbars, you can underline them or put a background on them...), but they hang, so they don't affect alignment.

[1] Note: When I say "like Safari", I mean with regards to hanging and to alignment. In addition to hanging the spaces, Safari also collapses the advance width of these spaces, so that they're not visible. This is allowed, but not required (and I would recommend not doing that) by the specification. Nobody is proposing to change that particular point.

GitHub Notification of comment by frivoal
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3440#issuecomment-517339591 using your GitHub account
Received on Thursday, 1 August 2019 15:34:29 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:41:51 UTC