DlData: prevent text overflow from being visible in padding #1110
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR fixes the issue described at getodk/central#670 (comment). In the image in that comment, you can see that an ellipsis appears at the end of the third line of text, yet text is also shown below the ellipsis. In other words, the text is visible in the bottom padding of the
<dd>
element.The
<dd>
element ofDlData
specifiesoverflow: hidden
, which might be why the text doesn't overflow into the next row. However,overflow: hidden
isn't enough to prevent the text from overflowing into the bottom padding.We have used
<dd>
+ theline-clamp
mixin for a while, inEntityData
. However, there, the<dd>
element doesn't have padding, which is why this hasn't been an issue in the past. This is an issue only as of #1077, since that PR added padding to<dd>
elements in.dl-horizontal
. To be clear, I still think it's the right approach to add padding to<dd>
elements, but I wanted to explain why we're only seeing this issue in hover cards.The way I'm solving this issue is by wrapping the text in a
<div>
without padding. I'm then addingline-clamp
and the tooltip to the<div>
rather than the<dd>
. Since the<div>
doesn't have padding, its text won't overflow into the padding. The<dd>
will still be free to have padding.What has been done to verify that this works as intended?
I tried it out locally.
From looking on the QA server, I think the value shown in the image is "54.6029931 18.2311011 72.70000457763672 23.649". Note that there are no newline characters in the value. The value is just wrapping because it's long.
Why is this the best possible solution? Were any other approaches considered?
Instead of adding an inner element (the
<div>
in this case), others have tried fixing theheight
of the outer element or adding a pseudo-element. I think adding a<div>
is the clearest approach.Another idea entirely would have been to prevent the text from wrapping at all. We could truncate the text at the end of the first line. However, more data will be visible if we allow the text to wrap a little, which I think is nice.
Before submitting this PR, please make sure you have:
npm run test
andnpm run lint
and confirmed all checks still pass OR confirm CircleCI build passes