-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
Fix wordbreak for URLs #36993
Fix wordbreak for URLs #36993
Conversation
This makes me happy! On my review list for today 🙇 |
Size Change: +32 B (0%) Total Size: 1.1 MB
ℹ️ View Unchanged
|
We also have PR with an alternative fix - #36980. |
d311789
to
fb0de30
Compare
I don't have a strong opinion on which fix is worth landing, but for some context on the additional properties I added, CSS tricks has a great rundown. |
Thanks, @jasmussen. I also don't have a strong opinion on this. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good Joen, thank! 👍
Personally I think this approach is better because it fixes the issue with just one css rule that does just what we want.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No strong options about which approach is best. The difference between the PR's is that #36980 truncates the URL.
09a6aa2
to
ecddfda
Compare
I can't quite figure out why the PHP unit tests keep failing. |
Ok, here's a "moderately warm" opinion 😅: given that users will still be able to see and edit the full URL, I'd prefer truncating the string as the other PR does, because the popover will be generally shorter. Here's an example of the same URL using this PR (left) and the other one (right). Also, notice that this PR does something weird with the title. |
Please can I sound a slight warning bell here that I've had lots of feedback from users in the past that they often need to be able to see the full URL. If we do go down this route for UX/UI reasons, please can we include a method for users to be able to see the full URL? Perhaps an expose on hover or a tooltip or something? 🙏 🙏 🙏 🙏 🙏 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for picking this one up 🙇
I have also tested and I like this PR because it involves no truncation of strings. The property used has good x-browser support as well.
As mentioned in #36993 (comment) I recommend we don't truncate unless we provide a means by which the user can still access the full URL.
+1 this makes sense. We could also increase the number of the truncated characters so we showed two lines at most instead of always one. |
Oh.. this is valid. We should apply the css rule in the url only. |
Here is the PR where I added word wrapping instead of clipping originally in response to the user feedback |
Thanks for the reviews. I'll take a look at the title when I get a moment! |
ecddfda
to
feba3e0
Compare
Thank you all for fixing this 🥳 |
* Fix wordbreak for URLs * Use break-all instead. * Remove overflow-wrap. * prefer the new css prop `overflow-wrap` * Only apply to URL. Co-authored-by: ntsekouras <[email protected]>
Description
Fixes #36961. URLs didn't wrap:
They do after this PR:
For what it's worth, I don't personally think it's that valuable to see the full URL like this, especially when it gets clipped in editing it after the fact:
But that's a not at all a strong opinion, so I've kept the behavior as is, given the CSS comment pointed to a particular issue.
How has this been tested?
Add a very long URL that does not include hyphens, and observe that it still gets broken up.
Types of changes
Bug fix (non-breaking change which fixes an issue)
Checklist:
*.native.js
files for terms that need renaming or removal).