Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make cell contents break lines even if a long word #9

Open
graybeal opened this issue Jul 20, 2014 · 7 comments
Open

Make cell contents break lines even if a long word #9

graybeal opened this issue Jul 20, 2014 · 7 comments

Comments

@graybeal
Copy link
Member

CF SN include some loooong terms, which force the cell widths in tables to the maximum term size.

This can be overridden with the CSS style
word-wrap: break-word; (and maybe also overflow-wrap: break-word)
for the cells in question. (see e.g., http://stackoverflow.com/questions/3058866/how-to-force-a-line-break-in-a-loooooong-word-in-a-div for details.)

I think it would be nice to have this as the formatting for our table cells. (Though once I see it I might change my mind....)

@carueda
Copy link
Member

carueda commented Jul 20, 2014

This will need a fixed width for the column (otherwise the break-word setting may not take effect). What width would you propose?

If you want to locally play with this:

adjust the following part in main.html

                <td field-name="name" style="white-space: nowrap;">
                    <div ng-bind-html="gridItem.name"></div>
                </td>

to

                <td field-name="name">
                    <div ng-bind-html="gridItem.name" style="width: 200px; word-wrap: break-word;"></div>
                </td>

@graybeal
Copy link
Member Author

Geez, is awkward. Fixing it in first column leaves the second column as an issue, setting both their widths fixed is lousy usability. And did you know when you set a fixed width column, the size of the column still changes with CMD-+ or CMD-–?

The better option might be to insert a breaking non-space (­ or ­) after every _. (This could require pulling it back out for other processes.) I think this goes somewhere in util.js, but have to leave it at that for now.

@graybeal
Copy link
Member Author

Well, learned lots of javascript and angular.js today.

It turns out that a workaround exists that supports the right word-wrapping behavior for every browser but firefox. The series of styles (in app.css, e.g., for tbody.ng-scope)

-ms-word-break: break-all;
   word-break: break-all;
 /* Non standard for webkit */
   word-break: break-word;

will cause long words to break, and still avoid breaking short words, in Chrome, Safari, and (allegedly) MS IE. (One did have to turn off white-space:nowrap for this to work.) But Firefox 30 just ignores spaces when it sees this.

So I tried to implement it only for the name field, which can be done with the class-attribute selector td[field-name="name"]. Then of course, the middle column tries to take over, because it has much more content, and all the names get brutally wrapped.

So you can try to fix that by setting the width of the first field. This works to a point, but as soon as there is a really long name in the Description field (as happens if you display all names at once), the Name field scrunches down again. And it's hard to find the right size for the Name field, though 30% is a reasonable shot.

I also tried using &shy; or <wbr> as mid-word separators, but browsers insert hyphens when they break words for these. This could be OK for the Description column, but not the name column.

So next I tried adding a style that was Firefox-only. I used the @-moz-document url-prefix() directive, but this does not seem to take effect as described. (Another note indicated it was deferred, hmm.)

I understand I could use javascript to detect firefox browsers. This seems possible, but about as marginal as using in long names in the Description column.

Or, we could just declare that it doesn't support firefox, then the word breaks work pretty well with the mod above. What do you think of that?

@graybeal
Copy link
Member Author

I have pushed my local changes, that work nicely on everything except firefox, to my better-word-breaks branch on GitHub, so you can take a look at them, if you are interested.

(Uh, sorry for the multiple commits, I'll try to clean that up before issuing a pull request. Or you can just pull the changes directly, if you want.)

@carueda
Copy link
Member

carueda commented Jul 23, 2014

I just (quickly) tested these adjustments locally. Concretely, with some minor adjustments (my IDE showed some warnings with the original changes, but easy to correct, it seems)

In app.css:

tbody.ng-scope {
   -ms-word-break: break-all;
       word-break: break-all;
}

and in main.html:

<th field-name="name"            enable-filtering="true" style="width: 35%"></th>

plus of course the removal of style="white-space: nowrap;" a couple on lines below:

<td field-name="name" >

And these adjustments seem to work ok even in Firefox (v. 30.0 on Mac):
image

(BTW, in general, we need to start doing some testing against IE as surely many users will be using such browser..)

Also, a good ref is https://developer.mozilla.org/en-US/docs/Web
In particular, according to https://developer.mozilla.org/en-US/docs/Web/CSS/word-break, it seems just the word-break: break-all; setting in the CSS would suffice ...

In any case, I would definitely prefer not breaking support for Firefox -- we should support any modern, widely-used browser.

@carueda
Copy link
Member

carueda commented Jul 27, 2014

Just a note that the unneeded white-space: nowrap; was removed e28ff9104.

Back to the requested change here, again, seems like the word-break: break-all; setting would be ok in general. I just note that the column gets really narrow if the window gets smaller and depending on the actual displayed descriptions; would that be a real issue (of course, forcing some minimum column width would be great, but I'm not sure how to accomplish that in at least a straightforward way)? BTW, there's a special route for testing purposes http://mmisw.org/cfsn/#/_flat that we could use. Right now it has the word-break: break-all; setting in the first column.

@graybeal
Copy link
Member Author

As implemented, the left column gets too narrow because the middle column does not have the same setting; so the middle column is staying wide because of wide words in it.

This setting does not work appropriately in firefox for Mac (the cited references are silent about how it should work, even). You'll notice in your second comment previous ("these adjustments seem to work ok even in Firefox"), that with the same setting for the center column, firefox is wrapping text mid-word. (Force-wrapping, I call it.) It is OK to force-wrap continuous words; it is not OK to force-wrap small words. And no matter how big the window or column is, firefox will still force-wrap small words and look bad.

So my prioritized list of solutions is (I care about this a little too much because it is a failure of the standard's designers and implementers, especially firefox):

  1. Use javascript to detect firefox and use this setting only on non-firefox browsers (letting firefox look bad because of wide columns)
  2. Figure out a way to insert the tiniest possible space after all underscores (not sure there's actually a way to do this, but something like <span style="font-size:1;text-color:"white">-<> should work)*
  3. Use this setting on all browsers and let firefox look bad with force-wrapped words
  4. Insert a dash of the same color as the background in the middle of long names in column 1
  5. Throw up our hands.

*I made some changes to try (3) a few days ago but couldn't quite get them to work, would need a little collaboration to be successful there. Let me know if you want me to pop them back into a branch.

Optionally for (1), we could Insert soft hyphens (­) after all the _ characters in the middle column for firefox browsers. I don't want it in the first column, because while it allows hidden breakpoints, (a) hyphens still appear when the word is broken, and (b) some in-browser searches will fail to match the text that's interrupted by soft hypens.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants