Open Bug 1253840 Opened 6 years ago Updated 4 months ago

text-align: justify; doesn't work together with white-space: pre-wrap;


(Core :: Layout: Text and Fonts, defect, P3)




Webcompat Priority ?


(Reporter: mezood, Unassigned)




(1 file)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:44.0) Gecko/20100101 Firefox/44.0
Build ID: 20160210153822

Steps to reproduce:

I just have a text-align: justify; together with white-space: pre-wrap; .

Actual results:

The text didn't justify.

Expected results:

The text should be justified.
Component: Untriaged → Layout: Text
OS: Unspecified → All
Product: Firefox → Core
Hardware: Unspecified → All
Version: 44 Branch → Trunk
This issue is fixed in chromium in 2014, so this is now a cross-browser compatibility issue.

For more details see:
Depends on: 299721
Ever confirmed: true
Attached file testcase

This is an issue in the default WordPress editor (Gutenberg "blocks" editor), which uses white-space: pre-wrap; in the standard view.

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).

Is there any priority on this bug?

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.

Severity: normal → S3
Priority: -- → P3

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.

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."

Webcompat Priority: --- → ?
You need to log in before you can comment on or make changes to this bug.