Closed Bug 1758391 Opened 2 years ago Closed 4 months ago

Convert text-wrap CSS property to a shorthand

Categories

(Core :: Layout: Text and Fonts, enhancement)

enhancement

Tracking

()

RESOLVED FIXED
124 Branch
Tracking Status
firefox124 --- fixed

People

(Reporter: sebo, Assigned: jfkthame)

References

(Blocks 1 open bug, )

Details

(Keywords: dev-doc-complete)

Attachments

(1 file)

CSS Text Module Level 4 defines a text-wrap property that specifies the mode for text wrapping.

See Also: → 654994
Blocks: 1846799

Bug 1731541 is introducing text-wrap, but only as a longhand to expose the text-wrap: balance value (which is already shipping in other browsers, and gaining traction on the web).

However, the spec is evolving to make both white-space (see bug 1852478) and text-wrap into shorthands, having some overlap in associated longhands, so once the bikeshedding dust settles we should do that restructuring here.

See Also: → 1852478
Summary: Implement text-wrap CSS property → Convert text-wrap CSS property to a shorthand
Blocks: 1861614

This depends on having text-wrap-mode, introduced in bug 1852478 as part of
turning white-space into a shorthand.

Depends on D198790

Assignee: nobody → jfkthame
Status: NEW → ASSIGNED
Pushed by jkew@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/01711557e2bf
Rename `text-wrap` to `text-wrap-style`, and create the `text-wrap` shorthand. r=firefox-style-system-reviewers,emilio
Flags: needinfo?(jfkthame)
Flags: needinfo?(jfkthame)
Pushed by jkew@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/c0fa98fec39a
Rename `text-wrap` to `text-wrap-style`, and create the `text-wrap` shorthand. r=firefox-style-system-reviewers,emilio

Backed out for causing build bustages in UseCounterMetrics.cpp

  • Backout link
  • Push with failures
  • Failure Log
  • Failure line: /builds/worker/workspace/obj-build/dom/base/UseCounterMetrics.cpp(1589,38): error: no member named 'css_text_wrap_mode' in namespace 'mozilla::glean::use_counter_css_page'; did you mean 'css_text_wrap'?
Flags: needinfo?(jfkthame)

Sigh... broken rebase. Trying again.

Flags: needinfo?(jfkthame)
Pushed by jkew@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/99028aaeb246
Rename `text-wrap` to `text-wrap-style`, and create the `text-wrap` shorthand. r=firefox-style-system-reviewers,emilio
Status: ASSIGNED → RESOLVED
Closed: 4 months ago
Resolution: --- → FIXED
Target Milestone: --- → 124 Branch
Duplicate of this bug: 1851315
Duplicate of this bug: 1861614

I feel that I may have found a very weird bug related to this, it only affects firefox when using :has() with a radio button, when setting text-wrap: balance; or text-wrap-style: balance; and only with the font Georgia.

I have created two codepens and the only difference is the font.

You can see that the :has() selector is working becasue the color of the text is changing.

I have also created other codepens that help prove this, both of which work as expected:

  • this is probably not the correct place to report this, but it's just so weird
Flags: needinfo?(jfkthame)

It'd be better to file a new report, so that we have the example on record as an open issue. (Comments on already-closed issues tend to get lost and forgotten...)

From a quick look, I think what you're seeing is a natural result of the "balancing" algorithm Firefox currently uses, which has the effect of minimizing the longest line length in the block. In this particular example, the original "un-balanced" layout has a longest line of 571px (line 2), and there's no alternative layout (given the available line-break options) that will be more compact. In the "balanced" result that I see in Chrome, the 3rd line actually ends up longer at 577px, although arguably their result may be better-looking in that the three lines have a more even spread of lengths (short, medium and long) rather than being two longer lines and one shorter.

Here's a codepen where you can see that this is the stable 3-line layout Firefox chooses for this particular text and font combination, as the available width varies.

Anyhow, I think it's behaving as expected given the algorithm in use, but that's not necessarily the final word; alternative heuristics could perhaps be considered. Again, feel free to file it as a new issue.

Flags: needinfo?(jfkthame)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: