-
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
Wrapping probably should happen for navigation #18337
Comments
I would love to see a consistent UI pattern for:
|
My slight caution over a fading out is it can look like a mistake. There are a few options we could have from '...' through to having the fading out. I would also love to see a consistent way to deal with this. |
👋 Hi there!! Navigation x Long content is always challenging. Especially with the inline-editing interactions that the Navigation Block is trying to achieve. I experimented a bit and created this prototype: I think truncation may be a good option when viewing the nav links (not editing). This can be achieved by having a max-width of some kind, and indicating the truncation with When editing the link, the NavigationItem should expand to full to enable the RichText editor to do its thing. Thoughts on the fading UI. From a technical perspective, this is more challenging compared to a Whereas with I'm not saying the fade effect is impossible :). It just requires more technical considerations. Hopefully the prototype + thoughts help!~ |
@mapk what do you think in this case about adding ... for now? |
Truncating the text with an ellipses is fine. Either case feels really odd in context to the block though. I'd love to get a fix in that helps resolve the long text issue right now and then iterate later on a more holistic, contextual approach. |
@mapk I think you are suggesting we get in '...' and consider an iteration? Do you have ideas on a more holistic approach here? |
How are default themes handling these cases currently? |
If we're likely to go with breaking long words in the future, I'd suggest that we implement it straightaway instead of the ellipses solution, because word-break is much easier (literally one line of CSS). We'll have to add that line in anyway if we go with the ellipses, because we should be displaying the whole text when focused, and we'll want the whole of our super-long word to be visible on the page while it's editable. If we do end up going with ellipses though, what character limit should be set? In English words are generally pretty short, but that's not the case in all languages. We'll need a value long enough that it doesn't cut off legitimate one-word navigation items 😅 |
@tellthemachines, let's try a simple CSS The longest German word, Dienstleistungen, is 13 characters. So let's go with that? |
This is a stress case but there is no wrapping so this can be created:
If we decide to just let someone do this, that's ok but it looks like this on front.
The text was updated successfully, but these errors were encountered: