Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[css-text-4] Renaming text-space-* to white-space-* #8273

Closed
fantasai opened this issue Dec 31, 2022 · 7 comments
Closed

[css-text-4] Renaming text-space-* to white-space-* #8273

fantasai opened this issue Dec 31, 2022 · 7 comments
Labels
Closed Accepted by CSSWG Resolution css-text-4 Needs Testcase (WPT)

Comments

@fantasai
Copy link
Collaborator

fantasai commented Dec 31, 2022 •
edited
Loading

In #448 @SebastianZ asked about renaming the text-space-collapse/trim properties to white-space-*. Historically there was some kind of conflict problem with XSL:FO's white-space-collapse, which takes a different set of values, which is why we had to rename it to something else.

I'm filing this issue to ask two questions:

  • Do we still have a conflict problem with XSL:FO?
  • If not, do we want to switch up the names to white-space-*?

CC @MurakamiShinyu @liamquin
@liamquin
Copy link

white-space-collapse in XSL-FO [1] when true replaces sequences of white space other than linefeed with the first white space in a sequence, so e.g. multiple spaces get turned into a single space everywhere.

white-space-treatment in XSL-FO [2] controls whether spaces go away around linefeeds, e.g. including after wrapping.

Although XSL-FO is certainly being used, and there are multiple active implementations, i'm not sure how much it matters if CSS itself has a property with a name used by XSL-FO. You could think of XSL-FO as an XML vocabulary that incorporates CSS for styling, though. Because of weird W3C process rules, the XSL-FO spec actually includes a copy of the CSS 2.1 properties, so that it could be published as a Recommendation, but the intent was that they would be the same. However, XSL-FO property values are generally expressions, almost as if they were implicitly surrounded with "calc(...)", so there are limits on how compatible they can be.

Antenna House have a product that implements both CSS and XSL-FO, so they might be affected, but, again, in FO mode the values are interpreted differently anyway.

A bigger question is whether users would be confused. However, XSL-FO is primarily used in cases where CSS for paged media isn't ready or isn't sophisticated enough, and the stylesheet authors are more likely to cope with the confusion than many other users. I do think it would be better to avoid the confusion if possible, though. It also seems to me that white-space-collapse might be confused with margin-collapse, so that inline-space-collapse might be better?

[1] https://www.w3.org/TR/xsl/#white-space-collapse
[2] https://www.w3.org/TR/xsl/#white-space-treatment

@MurakamiShinyu
Copy link
Collaborator

I worked on Antenna House's XSL-FO & CSS implementation in the past, but presently I am not in that position. So this is my guess, but they and their users will not be much troubled by this renaming, because properties of XSL-FO and CSS are already quite different.

My impression is that "white-space-*" is a natural naming for the longhand properties of the "white-space" shorthand property.

@fantasai
Copy link
Collaborator Author

Thanks very much, @MurakamiShinyu and @liamquin ! Agenda+ to propose renaming.

It also seems to me that white-space-collapse might be confused with margin-collapse, so that inline-space-collapse might be better?

No, CSS authors are used to white-space referring to actual space characters and not to margins or padding. Meanwhile inline is currently used as a prefix/suffix indicating things affecting the inline axis vs the block axis (e.g. we have margin-inline as a shorthand for margin-inline-start and margin-inline-end, which are our equivalents to XSL's margin-start and margin-end).

@SebastianZ
Copy link
Contributor

SebastianZ commented Jan 30, 2023 •
edited
Loading

Another reason to rename text-space-* is that it can easily get confused with text-spacing (and possible longhands as discussed in #4246).

And the reason why I proposed to rename them to white-space-* is that those properties are meant to be longhands for the white-space property.

Sebastian

@fantasai
Copy link
Collaborator Author

fantasai commented Feb 2, 2023 •
edited
Loading

@SebastianZ There's no doubt in my mind that white-space-collapse is the better name. We were asked to move away from that by the XSL:FO folks a couple decades ago; but since Liam and Murakami think it's okay I think the obvious thing is to rename them back.

@css-meeting-bot
Copy link
Member

The CSS Working Group just discussed [css-text-4] Renaming text-space-* to white-space-*, and agreed to the following:

  • RESOLVED: rename `text-space-collapse` back to `white-space-collapse`
The full IRC log of that discussion <dbaron> fantasai: This issue... a long time ago we had a `white-space-collapse` which together with `text-wrap` were longhands of `white-space`.
<dbaron> fantasai: XSLFO folks complained that, since we organized the value space to be spimpler than XSLFOs, complained about naming collisoon, so we renamed (but less clear)
<dbaron> fantasai: 2 decades later, we want to rename back, confirmation from Liam Quin and Murakami-san that it's OK to rename back to the more easily understood name.
<dbaron> astearns: Implementation status of text-space properties?
<dbaron> fantasai: AS far as I know, nobody.
<fantasai> s/we want/someone asked/
<dbaron> astearns: so good time to rename
<dbaron> astearns: any concerns with going back to `white-space-collapse`?
<dbaron> RESOLVED: rename `text-space-collapse` back to `white-space-collapse`
<SebastianZ> Perfect!

@mozilla-apprentice mozilla-apprentice mentioned this issue Feb 22, 2023
Closed
@chromium-helper chromium-helper mentioned this issue Feb 22, 2023
Closed
@fantasai
Copy link
Collaborator Author

fantasai commented Mar 1, 2023

Fixed in 3050d05

@fantasai fantasai closed this as completed Mar 1, 2023
aarongable pushed a commit to chromium/chromium that referenced this issue Mar 2, 2023
@kojiishi
[white-space] Split wrapping and break-spaces
1f48009 
In the previous refactoring to avoid using `EWhiteSpace`[1][2],
the `break-spaces` was combined with `text-wrap` because the
spec hasn't determined yet and it was natural for our code.

Now it was put on the `white-space-collapse` property. This
patch:
* Incorporates naming change of `text-space-collapse`[3].
* Split functions for wrapping and `break-spaces` because they
  will be on separate properties.

Some of rewrites check `ShouldWrapLine()` and some don't. This
aligns with the code before the refactoring[1][2].

This patch has no behavior changes.

[1] https://chromium.googlesource.com/chromium/src/+/fbbeeb9e8237c7bafbbc8129977aa603dd2d3d7b%5E%21/third_party/blink/renderer/core/layout/ng/inline/ng_line_breaker.cc
[2] https://chromium.googlesource.com/chromium/src/+/d23707305dd5d94c39486d1d0665fc63d091c4bf%5E%21/third_party/blink/renderer/core/layout/ng/inline/ng_line_breaker.cc
[3] w3c/csswg-drafts#8273

Bug: 1417543, 1418455
Change-Id: Ib10b602ed985681df6d2bf3768d2245f176253a1
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4301459
Auto-Submit: Koji Ishii <[email protected]>
Commit-Queue: Koji Ishii <[email protected]>
Commit-Queue: Yoshifumi Inoue <[email protected]>
Reviewed-by: Yoshifumi Inoue <[email protected]>
Cr-Commit-Position: refs/heads/main@{#1112101}
fantasai added a commit that referenced this issue Mar 16, 2023
@fantasai
[css-text-4] Rename text-space-trim to white-space-trim. #8436 #8273
54c3e0c
@frivoal frivoal mentioned this issue Aug 23, 2023
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Closed Accepted by CSSWG Resolution css-text-4 Needs Testcase (WPT)
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@frivoal @fantasai @SebastianZ @MurakamiShinyu @liamquin @css-meeting-bot