Sometimes Datagrid doesn't break cell content when it needs to wrap it. This leads to cell content overlaying next cell(s) in its row.
Text content should be wrapped even if it should break word.
App
Device:
I also noticed in this particular code example, that adding checkbox column affects columns layout much more, than it feels it should, not saying about improper layour changes on resize - bugs for this are already created, I guess.
Hi Sergey,
Although it is easy to just put text in the datagrid and expect it to be handled well, word-wrap it, word-break it, etc, we prefer to look at the datagrid cells as mere containers for your content and not impose any formats or restrictions on them. When the content happens to be unformatted text that does not handle word-wrapping/breaking, then that's how it will be rendered.
It's quite easy to add this behavior to your content, or even to the clr-dg-cell container, like in this fork of your example:
https://stackblitz.com/edit/clarity-break-all-demo
I'll leave this issue open for now, so other teammates may comment if there have been any previous discussions on this topic and if we have plans to add some default content helper components or anything in this line of thought in the future.
@Jinnie I bet such behavior is not what most people would expect. Breaking words is a sane default IMO, especially as Datagrid layout breaks otherwise. Also, as far as I understand, this is going to be a breaking change, as I don't remember having such problems before 1.0.
I understand that workaround is trivial, but why making this default, when most people will not be OK with such default, plus it breaks whole Datagrid layout?
It turns out "most people" don't agree with what the sane default should be. Some people want word-break: break-all like you, and some people want text-overflow: ellipsis. Note that you only have the problem on long non-breakable strings, we do wrap correctly on text that contains spaces.
Implementing word-break: break-all as the default like you suggest would actually be extremely problematic for normal text with spaces. Right now, we wrap like this:
This is a regular paragraph
of text. Breaking in
between words makes it
easy to read.
With your suggestion, it would break in the middle of words like this:
This is a regular paragr
aph of text. Breaking in
the middle of words ma
kes it hard to read.
We consider regular text with spaces to be the default, and any special format like 50-characters IDs or underscore-chained usernames to be app-specific edge cases. As such, we decided to keep the default of breaking between words and other solution like breaking everywhere or truncating with ellipsis is up to the app. Given the fact that it's just one simple line of CSS, we figured it was a reasonable decision. See #1146, #815 and #618 for previous discussions on this.
That said, I'm really surprised the datagrid in your example doesn't just have a long horizontal scroll. That used to be the case and it seems to be only half-working right now. I will mark this as a bug that needs investigation, but please note that the expected behavior in your demo is to have very wide cells and long horizontal scrolling.
Thanks for reporting this. 馃憤
Yes, I tried reproducing it on 0.13 and the same code leads to a datagrid with a long horizontal scroll.
@sdurnov: I just noticed you are using [clrDgRowSelection]="true" and row actions at the same time. As mentioned in our documentation:
Do not use [clrDgRowSelection] if your row contains any type of clickable elements (buttons, links, inputs, expand caret, single-row actions, etc.). Doing so would produce invalid HTML in the form of nested buttons, which will break in various unpredictable ways depending on the browser.
It has nothing to do with the issue you are facing, but I wanted to point it out if you have the same pattern in your app. As a general note, we support this [clrDgRowSelection] for legacy reasons but we recommend against using this feature unless you have a very specific use case that requires it, due to the various accessibility concerns it raises and the risks of someone else on your team adding actionable elements inside of the row and suddenly breaking for various browsers.
One issue in play here is related to [clrDgRowSelection]="true" that makes whole row clickable. When the datagrid is flipped into calculation mode for the smart-sizing of column headers and cells the label used to make the who row clickable is not hidden. However, hiding the label with css doesn't fix the whole issue, column widths are closer to the calculated width but are not rendering with that size. I'm continuing to investigate this along with the column width issues.
My proposal is to make the overflow invisible instead of breaking long words. Like this:
https://stackblitz.com/edit/datagrid-long-content?file=src%2Fapp%2Fapp.component.html
As @youdz said, we're already breaking on whitespace and that's enough.
While breaking within words will be too intrusive, just cutting the overflow will prevent bleeding of content in adjacent columns or outside the grid.
This will be a rather gentle way to force the users to implement their own additional handling if needed. Without possibility for a broken layout. If this will interfere with future work, we can address it when it is being implemented.
If we agree on this, I can take the task and add the overflow clipping.
@Jinnie I would add an ellipsis to make it look more elegant and make it a default behavior. But I would also add optional behavior to break words as well.
@Jinnie: As mentioned in the various I linked above, we can't have any kind of overflow: hidden on datagrid cells in Clarity. Cells can contain anything, in particular content that is supposed to overflow like tooltips.
Matt and I will be looking at this, but the expected "fix" is still to restore the previous behavior which is a long horizontal scrolling. Then you'll be able to set the width of the columns and have an ellipsis in the app's CSS if you need to.
PS: you don't need ::ng-deep in your CSS, the clr-dg-cell elements are owned by the app component. 馃槈
This issue is also related to #1725.
The changes in https://github.com/vmware/clarity/pull/2938 also return the rendering behavior to how it used to be in Clarity versions prior to v1.0.0 for this use case. @sdurnov - I tried to check the original stackblitz that reported this issue. It seems to have been deleted. I re-created the issue as best I could from memory. Can you verify that its valid for your use case case? If not please reopen so I can investigate further.
As I also looked at this case, I have my own reproduction stackblitz and I can confirm that it looks as expected with 1.0.2 馃憤
FYI. I found the CSS "word-wrap:break-word" to work best to intelligently split long text ie. preferably at words but to break word if too long. Working on Chrome, Edge, IE. I use it on datagrid cols that may overflow otherwise.
Hi there 馃憢, this is an automated message. To help Clarity keep track of discussions, we automatically lock closed issues after 14 days. Please look for another open issue or open a new issue with updated details and reference this one as necessary.