text-align: justify; doesn't work together with white-space: pre-wrap;
Categories
(Core :: Layout: Text and Fonts, defect, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox115 | --- | fixed |
People
(Reporter: mezood, Assigned: jfkthame)
References
(Depends on 1 open bug)
Details
(Keywords: webcompat:platform-bug)
Attachments
(5 files)
Updated•9 years ago
|
Comment 1•9 years ago
|
||
Comment 2•9 years ago
|
||
Comment 3•4 years ago
|
||
This is an issue in the default WordPress editor (Gutenberg "blocks" editor), which uses white-space: pre-wrap;
in the standard view.
- https://support.mozilla.org/questions/1303902
- Reduced test case: https://jsfiddle.net/f2bLq95s/
Applying or removing Justify alignment is not visible in the editor, you need to use Preview to see what you've done.
WordPress is a popular platform, but text-align: justify needs to be added using a plugin, it is not a native feature.
I'm not sure what priority that implies (priority is not set for this bug).
Assignee | ||
Comment 5•4 years ago
|
||
I think it would be nice to handle this, though there are a few issues to keep in mind:
(a) The CSS2.1 spec explicitly said that browsers must not justify when pre-wrap
is in effect:
If an element has a computed value for 'white-space' of 'pre' or 'pre-wrap', then neither the glyphs of that element's text content nor its white space may be altered for the purpose of justification.
So according to CSS2.1, the Firefox behavior here was correct. This is also reflected in web-platform-tests that Firefox and Safari currently PASS, while Chrome FAILS.
(b) The CSS Text 3 spec relaxed this requirement, leaving it up to the user agent to choose whether or not to justify in this case:
If an element’s white space is not collapsible, then the UA is not required to adjust its text for the purpose of justification and may instead treat the text as having no justification opportunities.
And the web-platform-test mentioned above has been annotated with MAY, to reflect that the behavior is no longer a requirement but an option.
So to change the behavior here would carry some risk of disrupting content that expects the CSS2.1-specified behavior. However, given that Chrome has been doing this for several years at this point, the compatibility risk is probably minimal. Still, sites (or tools) really shouldn't be relying on a behavior that is explicitly called out as optional in the spec, and seems to be implemented by only one of the major engines at this point. (Is there a corresponding webkit bug open about this?)
I'll also note that Chrome does not actually follow the CSS Text 3 requirements fully; the spec goes on to say:
If the UA chooses to adjust the text, then it must ensure that tab stops continue to line up as required by the white space processing rules.
but in my brief testing, it seems to totally lose track of tab stops in this case.
Very interesting, thanks.
Are there any discussions for this? Would be super interesting to understand how they decided on this.
The problem that I am trying to solve and many other devs, is building a rich text editor/viewer that supports justification like in word/docs and other tools.
I don't know what are the considerations of the css spec writers. But I think this is a feature that should be implemented natively in browsers.
Currently, most online text editors either don't support justification or have a "broken" experience with different browsers. While there is wide demand.
This is the webkit bug https://bugs.webkit.org/show_bug.cgi?id=84448
I have also experienced this bug. In creating a web based page layout tool where typesetting is crucial this bug is easily reproduced when using "text-align: justify" in conjunction with "white-space: pre" or "white-space: pre-wrap."
Updated•3 years ago
|
Updated•3 years ago
|
Updated•3 years ago
|
Comment 9•3 years ago
•
|
||
This is affecting Word online editor (Microsoft Office 365), where applying "justify" doesn't have any effect on text alignment. Adjusting webcompat priority to P2
Comment 10•2 years ago
|
||
(In reply to Jonathan Kew [:jfkthame] from comment #5)
So according to CSS2.1, the Firefox behavior here was correct. This is also reflected in web-platform-tests that Firefox and Safari currently PASS, while Chrome FAILS.
FWIW, Safari fails this test now (possibly due to them having aligned with Chrome on this?)
Firefox is alone in passing that test now (where it sounds like maybe the web depends on us changing behavior?)
Assignee | ||
Comment 11•2 years ago
|
||
We should probably go ahead and do this, to align with the other browsers, and the spec and test should be updated accordingly.
But I think fixing this will also require us to fix bug 1712703, otherwise the justification will be inaccurate, so marking that as a dependency (and that looks like being the harder part of the task).
Assignee | ||
Comment 12•2 years ago
|
||
The CSS Text 3 spec allows this (CSS2 didn't), and other browsers
support it, so for better webcompat/interoperability, we should do the
same. Tests will need updating accordingly.
This first patch enables the property to take effect, but the resulting
layout is not yet correct because the (non-collapsed) whitespace at line
wrap positions needs to be forcibly "hung" into the margin for correct
justification; see following patch.
Updated•2 years ago
|
Assignee | ||
Comment 13•2 years ago
|
||
Depends on D178210
Assignee | ||
Comment 14•2 years ago
|
||
Depends on D178211
Assignee | ||
Comment 15•2 years ago
|
||
Depends on D178212
Comment 16•2 years ago
|
||
Comment 18•2 years ago
•
|
||
Backed out for causing multiple failures in nsLineLayout.cpp.
- Backout link
- Push with failures
- Failure Log
- Failure line: Assertion failure: applyState.mGaps.mHandled == applyState.mGaps.mCount (Unprocessed justification gaps), at /builds/worker/checkouts/gecko/layout/generic/nsLineLayout.cpp:3207
And also these reftests failures.
- Failure Log
- Failure line: REFTEST ERROR | TEST-UNEXPECTED-FAIL | layout/reftests/text/justification-1.html == layout/reftests/text/justification-1-ref.html | application timed out after 370 seconds with no output
Comment 20•2 years ago
|
||
Comment 21•2 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/0397755aaebe
https://hg.mozilla.org/mozilla-central/rev/e9ba463e16b8
https://hg.mozilla.org/mozilla-central/rev/838411d789f3
https://hg.mozilla.org/mozilla-central/rev/c412301a7e7c
Comment 22•2 years ago
|
||
Comment 23•2 years ago
|
||
The land in comment 22 is about these test unexpected-passes on central. The test is skipped on autoland and that's why it didn't turn orange there. https://treeherder.mozilla.org/logviewer?job_id=416520547&repo=autoland&lineNumber=1967
Comment 25•2 years ago
|
||
bugherder |
Comment 26•2 years ago
|
||
the web-platform-test mentioned above has been annotated with MAY
(...)
test should be updated accordingly
Jonathan and other Mozilla bugzilla colleagues in this bug report,
The CSS2-based test text/text-align-white-space-003.xht has now been removed from WPT test repository:
https://github.com/web-platform-tests/wpt/pull/40109
and the new tests from phabricator.services.mozilla.com/D178213 have been merged into WPT repository.
Comment 27•2 years ago
|
||
Comment 28•2 years ago
|
||
Thanks!
(While I'm here: --> closing needinfo from comment 18.)
Comment 29•2 years ago
|
||
Backed out for causing Bug 1838525
Backout link: https://hg.mozilla.org/releases/mozilla-beta/rev/2f3cce1e72fe61e4643225e21ac84ccebe84ed30
Comment 30•2 years ago
|
||
The bug is fixed. Only the annotation needed backout because it was a mistake, it should've been attached to bug 1834081 instead of here.
Updated•2 years ago
|
Comment 31•2 years ago
|
||
Restoring the status flags granted from comment 21 which were removed as part of the backout in comment 29.
Per comment 30, only a test-annotation was backed out here; the actual code changes stayed in.
Updated•5 months ago
|
Description
•