658883 - word-wrap: break-word implementation

Status: UNCONFIRMED

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

Description

[JDev]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.17) Gecko/20110420 Firefox/3.6.17 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.17) Gecko/20110420 Firefox/3.6.17 (.NET CLR 3.5.30729)

When using the word-wrap: break-word the browser attempts to move text down a line prior to applying word-break.  I believe this to be inconsistent with the intent of word-wrap: break-word.

Reproducible: Always

Steps to Reproduce:
1. Enter text in a div of fixed size
2. apply word-wrap: break-word to div
3.

Actual Results:  
Text appears as, example:

The 
antidisestablishmen
tarianism movement

Expected Results:  
Text should appear as, example:

The antidisestablis
hmentarianism 
movement

The reason for this is that

the line appears as, example:

The|antidisestablishmentarianism|movement

(| denoting acceptable break points)
break-word applies when there no acceptable break points, in this case in the word antidisestablishmentarianism

This should create a new line containing
hmentarianism|movement where either movement should be broken or put on a new line.

I believe this is actually a flaw in the standard to some extent as there is no defined threshold for an acceptable break point.  Ideally a user set percentage of the line to be used should be in place.  Example:

word-wrap: break-word 50%;
Would require that 50% of the available space be used before looking for an acceptable break point.

and/or

word-wrap: break-word 7ch;
Would require that break-word only be applied to words 7 characters or longer.

I'm not suggesting Mozilla go outside the standard but I don't think the current implementation is correct either.

Comment 1

[Simon Montagu :smontagu]

I think that would be an excellent addition to the standard. Manual typewriters in the last century had a similar feature: a bell would ring at a user-configurable number of characters before the end margin, so typically if a typist had begun a too-long word before the bell rang there would be a forced mid-word line break, but if the bell had already rung the typist would break before the word.

Earlier versions of CSS3 text had a value "text-wrap: unrestricted" which would have prevented breaking at an acceptable break point before a long word, but it seems to have been omitted from the latest version.

Comment 2

[fantasai]

'text-wrap: unrestricted' was removed because nobody had a use case for it.

I think your example is interesting, Mark, but would it not be better-served by hyphenation?

Comment 3

[JDev]

For that particular example perhaps, though hyphenation has it's drawbacks when changing font styles, especially dynamically.

Another example which might flush it out a bit would be:

div {
width: 95px;
text-align: justify;
word-wrap: break-word;
}

<div>It's a beautiful day in the neighbourhood.</div>

This creates large gaps in the text while only wrapping the last 2 characters where one might reasonably expect it to wrap first then justify.

A use case similar to this on trueachievements.com's latest blog post list is what got me interested in this issue.  Specifically where titles of a maximum length but unknown content needed to fit in a fixed width but flexible height box.  The results are wildly unpredictable currently as the title content does not necessarily contain real words (personal blog entries).  

An example, while very fringe case, the title contained:

.. .- -- .- .-.. .. ...- .

This is actually the name of an achievement in Assassin's Creed Brotherhood.  Adding a hyphen into this changes it's meaning entirely (I believe it's intended to be morse code or something similar).  While fringe case it illustrates the issue for languages, codes, alternate form (symbol/l33t speak), or non-language text which may require functionality akin to hyphenate-limit-zone but without an actual hyphen.  

If I may be so bold, the two could have so much overlap that it might also make sense to combine them and hyphenate only if a hyphenate-character is set.  At this late stage I doubt it is feasible.

Comment 4

[JDev]

An additional thought that I've not investigated but it would make sense that mathematical formulas would also be negatively affected by hyphens (excuse the play on words) unless this is being detected in the hyphens implementation?

Comment 5

[Jonathan Kew [:jfkthame]]

(In reply to comment #3)

> Another example which might flush it out a bit would be:
> 
> div {
> width: 95px;
> text-align: justify;
> word-wrap: break-word;
> }
> 
> <div>It's a beautiful day in the neighbourhood.</div>
> 
> This creates large gaps in the text while only wrapping the last 2
> characters where one might reasonably expect it to wrap first then justify.

Similar behavior occurs in most text-layout applications, I think. The normal approach is to create successive lines by breaking at "legitimate" break positions whenever possible, which leads to a break immediately before "neighbourhood", and only break a word (in the absence of hyphenation) as a last resort when there is *no* acceptable break earlier in the line.

It's true that this occasionally gives visually poor results in extreme cases, but doing something "better" starts to move us into the realm of whole-paragraph optimization along the lines of TeX or InDesign's "paragraph composer". In general, CSS layout will become significantly more challenging to implement if we go beyond the line-by-line approach to paragraph construction, and allow the break positions found (or not) at line N to affect break decisions not just for line N and its successors, but also for line N-1, and perhaps even N-2, etc.

Comment 6

[Jonathan Kew [:jfkthame]]

Attachment: examples of similar line-breaking behavior in other apps

Screenshot showing equivalent behavior in MS Word (left) and Apple TextEdit (right) on OS X.

Comment 7

[JDev]

(In reply to comment #5)

> It's true that this occasionally gives visually poor results in extreme
> cases, but doing something "better" starts to move us into the realm of
> whole-paragraph optimization along the lines of TeX or InDesign's "paragraph
> composer".

Without moving into the realm of TeX this type of functionality is being implemented in hyphenate-limit-zone, hyphenate-limit-chars, hyphenate-limit-word is it not?  Or is Mozilla not implementing this optional part of the standard?

Comment 8

[Jonathan Kew [:jfkthame]]

(In reply to comment #7)
> (In reply to comment #5)
> 
> > It's true that this occasionally gives visually poor results in extreme
> > cases, but doing something "better" starts to move us into the realm of
> > whole-paragraph optimization along the lines of TeX or InDesign's "paragraph
> > composer".
> 
> Without moving into the realm of TeX this type of functionality is being
> implemented in hyphenate-limit-zone, hyphenate-limit-chars,
> hyphenate-limit-word is it not?  

Somewhat, though in general that doesn't provides nearly as good a solution as the TeX approach can offer. (And the difference becomes increasingly important in the extreme cases with narrow measures and long words.)

> Or is Mozilla not implementing this
> optional part of the standard?

There's been no work on it yet (AFAIK), though I'd certainly be interested in future enhancements in this area. (Though I'm not sure how close those properties are to being stable, either.)

Comment 9

[Karl Dubost💡 :karlcow]

Attachment: firefox, safari, chrome

This is the current rendering in Firefox Nightly, Chrome Canary, Safari Tech Preview.

Exactly the same. I understand the desire, but this should be probably be discussed in the CSS WG, given that for now there is interop here. 

I wonder what Edge is doing for this.

Comment 10

[Karl Dubost💡 :karlcow]

I used for the test case with a 384px wide window.
data:text/html,<p style="word-wrap:break-word">The supersupersupersupersupersupersupersupersupersupersupersuperlongstring movement</p>

Comment 11

[Karl Dubost💡 :karlcow]

Should this block Bug 99457 the same way that Bug 389710 does?

Comment 12

[Jonathan Kew [:jfkthame]]

(In reply to Karl Dubost :karlcow from comment #11)
> Should this block Bug 99457 the same way that Bug 389710 does?

I don't think so; AFAICS, the word-wrap (overflow-wrap) property (bug 99457) is implemented correctly. The reporter here is looking for slightly different behavior, but that's something that would first need to be worked out in the spec.

If anything, this could block bug 1451459, as the additional hyphenation controls mentioned in comment 7 are now being defined in CSS Text 4. (I'm not aware of any actual browser implementation at this point, though would be interested to know if there is one.) Any additions/modifications to how overflow-wrap behaves would also need to be spec'd.

Comment 13

[709922234]

Nightly(v68) now supports this property.

https://developer.mozilla.org/en-US/docs/Web/CSS/word-break

Comment 14

[Boris Zbarsky [:bzbarsky]]

Emilio, is this bug fixed by bug 1296042? Or should it be marked invalid? Or is there still an issue here?

Comment 15

[Emilio Cobos Álvarez [:emilio]]

word-wrap: break-word has been implemented since forever (bug 99457), and works the same everywhere.

This bug is more of a change / feature request, if I understand correctly, to change the implementation minimize the amount of whitespace in a single paragraph.

I assume comment 13 meant word-break: break-word, which is bug 1296042, but that's not relevant here.

Any sort of automatic breaking like that would need to be at least two-pass, IIUC, so I suspect it's a no-go, but there's other proposal about setting the minimum width of the word to break or such that conceptually could be implemented.

Jonathan may be a better candidate to decide what to do with this bug.

Comment 16

[Jonathan Kew [:jfkthame]]

Looking all the way back to the original report in comment 0, I think the request is a reasonable one, but it's unclear to me exactly how this should be controlled in CSS, let alone implemented in the browser.

Given that the current behavior appears to be interoperable across all the major browsers, we should not simply change the existing behavior of overflow-wrap:break-word, even though the behavior suggested here looks like it would often be preferable.

So while there are some interesting ideas in the comments above, it's unclear how best to move forward. What I think needs to happen is for someone to design a specific proposal for a new/better behavior, and how to express it in CSS, and get CSS working group buy-in.

Comment 17

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

fantasai may have thoughts on whether/how to include it in CSS

Comment 18

[fantasai]

UAs are allowed to use whatever algorithm they want for deciding which break point to take: CSS only defines where breaks are allowed, not which ones are taken. It would be perfectly spec-conformant to improve the results here, and this is indeed one of the reasons why we're not prescriptive about the line-breaking algorithm. We want UAs to do better than they have historically.

That said, there is some concern about what the Web-compat impact would be. I do suspect most of the time when pages are sensitive to which break is taken (rather than just whether or not the text breaks), it's when laying out atomic inlines--but that's not really an issue here because we're breaking text specifically. So it might be worth experimenting with better line-breaking in these cases without introducing new syntax, to see if we can just do it.

If a switch is necessary due to Web-compat, text-wrap in Text Level 4 is introducing a keyword to opt into "prettier, but potentially slower and different" line-breaking, and that can be used as an opt-in.