Setting word-wrap: break
works (in the technical sense) for percentage widths, too, it seems to fail for tables with percentage widths for cells/columns, even when table-layout
has been set to fixed
. To work around this, it seems necessary to add line breaking hints into the content.
The old line breaking hint is <wbr>
, but some browsers now have issues with it. The new line breaking hint is the ZERO WIDTH SPACE character, which can be written as ​
or as such (when using UTF-8); it works well in modern browsers but causes nasty effects on old versions of IE. I tend to vote for the latter these days, but on my page on line breaking issues, I explain that there is a “bulletproof” but awkward method: use <wbr><a class=wbr></a>
with the CSS rule .wbr:after { content: "\00200B"; }
. When you generate a page programmatically, such clumsy markup might be feasible.
You should insert such hints only when needed. They should not be used for words in natural languages. As a simple approach, when you process user input for rendering on your page, you could split it to “words” in the technical sense (maximal non-whitespace strings) and then, for every “word” longer than N characters, insert a line breaking hint after any K characters. The parameters N and K would need to be selected according to your layout. The drawbacks: This would cause “emergency breaks” as if a string contained a space but doesn’t, and this could arbitrarily break long natural-language words, too.
Perhaps you could do things client-side, first running Hyphenator.js, then processing the text content so that you split the text content into fragments at any whitespace and at any soft hyphen (\00AD
; you need to make sure that you do this only after Hyphenator.js has completed its work). Then you can run the algorithm above on the fragments, i.e. add line breaking hints to long fragments.