Closed Bug 734358 Opened 12 years ago Closed 12 years ago

CSS hyphenation doesn't work with mixed characters

Categories

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

x86
macOS
defect
Not set
normal

Tracking

()

RESOLVED INVALID

People

(Reporter: kenneth, Unassigned)

Details

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_3) AppleWebKit/535.11 (KHTML, like Gecko) Chrome/17.0.963.78 Safari/535.11

Steps to reproduce:

I created a layout using table-cell, and floats, to have a two column layout with a dynamic width. To ensure the layout stays the same even with very long strings, I added CSS hyphenation to make gecko split up the sting.

More details can be found in my post http://blog.kenneth.io/blog/2012/03/04/word-wrapping-hypernation-using-css/



Actual results:

It seems like the hyphenation doesn't work with mixed characters. 

In the attached test case I have two layouts, one with alphanumeric chars, which looks good, and another one, which has mixed chars (token from a URL). The last example seems to confuse the hyphenation.

I can't figure out what goes wrong. If its a special character, or what it is. What I know is, that this combination breaks it.

See test case: http://dabblet.com/result/gist/2006370/aec05fe7abd7a16310999622bef4efd0f596f6ba


Expected results:

I would expect the hyphenation to break up the words, even if its mixed chars.
Hyphenation is intended for real words in real languages. It uses rules based on the patterns found in actual words of the language. So it shouldn't be expected to do anything sensible with arbitrary strings of characters such as your URL example. Occasionally there might be a sequence of letters in such a URL that happen to match one of the hyphenation patterns, but this isn't an appropriate use of the feature.
Status: UNCONFIRMED → RESOLVED
Closed: 12 years ago
Resolution: --- → INVALID
Makes sense Jonathan. Looking for a alternative.  Thanks.
Do you want something like "word-break: wrap"?
@Boris, Something like it. WebKit has already implemented word-break: break-word, which is non-standard. But since word-break isn't implemented at all in Gecko, I'm looking for alternatives to solve my current issues.

Support for CSS3 :overflow-wrap: break-world, would solve my issues going forward.
> Support for CSS3 :overflow-wrap: break-world, would solve my issues going forward.

We implement "word-wrap:break-word" to the same effect, for legacy reasons.  See the text at the end of http://dev.w3.org/csswg/css3-text/#overflow-wrap
word-wrap: break-word/ overflow-wrap: break-word, is the behaviour I want, but as documented in my article (http://blog.kenneth.io/blog/2012/03/04/word-wrapping-hypernation-using-css/), word-wrap: break-word doesn't work with dynamic widths

Is this by spec, or how you guys have chosen to implement word-wrap: break-word?

Notice that WebKit has implemented "word-break: break-word", not "word-wrap: break-word".
The behavior you see there is per spec.

Your issue isn't dynamic widths; your issue is shrink-wrap widths, no?  Per spec, overflow-wrap will only trigger when the text would overflow the container, but in your case you're telling the container to be as wide as it needs to be to contain the longest word in it (not explicitly, but that's the behavior table cells have; in fact table cells are even worse in that they _never_ go below their min-intrinsic width).

If you weren't abusing a table cell here, it would all work fine.  Why is the table cell needed, exactly?
I'm abusing the table-cell, to achieve a column-based layout, but when thinking about it, something similar could be achieved using floats, and a new block formatting context.
You need to log in before you can comment on or make changes to this bug.