The subject of wrapping text in a cell with CSS is reasonably well documented, and we recently investigated a specific case where the use of the standard ‘options/commands’ didn't seem to be having the desired effect. This was complicated by the fact that the target cell was a variable width.

The obvious commands are:

word-wrap  - which can take the one of two optional parameters:  ‘normal’ which will break words only at allowed break points; and ‘break-word’ which allows unbreakable words to be broken.

word-break – which has three possible values: ‘normal’ which breaks non-CJK scripts according to their own rules; ‘break-all’ where lines may break between any two characters for non-CJK scripts; ‘hyphenate’ where words may be broken at an appropriate hyphenation point.

Despite ‘playing’  with these the text was not breaking at the end of suitable values.

To cut a long story short, the problem was the actual text itself.  The text was a ‘cut and paste’ of an error message generated from a MySQL database. This consisted of an SQL insert statement where the various fields and the associated values were all separated by commas.  The text looked similar to that below:

SQL=INSERT INTO `jos_it_issues` (`id`,`alias`,`issue_summary`,`issue_description`,`identified_by_person_id`,`identified_date`,`related_project_id`,`assigned_to_person_id`, `issue_type`, `status`, `state`, `ordering`, ‘priority`,target_resolution_date`,`progress`,`actual_resolution_date`,`resolution_summary`,`created_on`,`created_by`,`modified_on`,`modified_by`) ……….

The obvious point,  (that is not immediately obvious sic) is that there is no space between the commas which separate the fields.  This means that there is no determined place that the ‘break-word’ instruction recognises for breaking the sentence.   ‘word-break: break-all’ works in as much as it breaks the line in places, but these may well be within a word itself.  What we required was to have the breaks after a comma, but this is not recognised by ‘word-wrap: break-word’.

The only solution we could come up with involved editing the SQL statement and placing a space after the commas.  This is still syntactically correct so retains the meaning of the SQL statement, but also allows the statement to be wrapping within the field.

One other associated point we observed was that as the statement was a ‘cut and paste’ there was some CSS ‘span’ and class’ statements also pasted into the cell.  This was not immediately visible in the WSIWIG editor with the result that the displayed page in HTML could possibly have undesirable effects if the classes are not as in source document..