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

Wrapping probably should happen for navigation #18337

Closed
karmatosed opened this issue Nov 6, 2019 · 11 comments · Fixed by #21632
Closed

Wrapping probably should happen for navigation #18337

karmatosed opened this issue Nov 6, 2019 · 11 comments · Fixed by #21632
Assignees
Labels
[Block] Navigation Affects the Navigation Block Needs Dev Ready for, and needs developer efforts [Status] In Progress Tracking issues with work in progress [Type] Bug An existing feature does not function as intended

Comments

@karmatosed
Copy link
Member

This is a stress case but there is no wrapping so this can be created:

image

If we decide to just let someone do this, that's ok but it looks like this on front.

image

@karmatosed karmatosed added the Needs Design Feedback Needs general design feedback. label Nov 6, 2019
@mapk
Copy link
Contributor

mapk commented Nov 7, 2019

Should we solve for this with a design exploration around fading out long words into a smaller space?

I'm thinking of something like this specifically, but am completely aware it may not be a great solution.

Screen Shot 2019-11-06 at 4 04 52 PM

@getdave
Copy link
Contributor

getdave commented Nov 11, 2019

I would love to see a consistent UI pattern for:

  1. Handling long strings of unbreaking text.
  2. Handling overflowing content which is "hidden" off screen but designed to be scrolled to (eg: a scrollable list of links where some items are hidden due to the scroll and fixed height).

@karmatosed
Copy link
Member Author

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.

@ItsJonQ
Copy link

ItsJonQ commented Dec 9, 2019

👋 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:
https://codesandbox.io/s/navigation-link-truncation-interaction-sbg0y

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 ... . The reason is because the Fade UI requires knowledge of the background color in order to render the fade effect (e.g. white -> transparent). This is okay if the Gutenberg editor's background is always white... but that might not always be the case. Therefore, we'd need background color awareness for both the Gutenberg back-end + front-end to achieve this effect.

Whereas with ..., it's just adding ... into the UI.

I'm not saying the fade effect is impossible :). It just requires more technical considerations.

Hopefully the prototype + thoughts help!~

@karmatosed
Copy link
Member Author

@mapk what do you think in this case about adding ... for now?

@mapk
Copy link
Contributor

mapk commented Dec 17, 2019

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.

@karmatosed
Copy link
Member Author

@mapk I think you are suggesting we get in '...' and consider an iteration? Do you have ideas on a more holistic approach here?

@karmatosed karmatosed removed the Needs Design Feedback Needs general design feedback. label Dec 18, 2019
@mapk
Copy link
Contributor

mapk commented Dec 18, 2019

Yep, that's what I'm suggesting. I think ellipses ... could work for now.

As for a holistic approach, I don't have anything fantastic. Maybe we break it similarly to how it breaks when editing the text?

Screen Shot 2019-12-18 at 2 39 20 PM

@obenland
Copy link
Member

obenland commented Jan 7, 2020

How are default themes handling these cases currently?

@talldan talldan added [Feature] List View Menu item in the top toolbar to select blocks from a list of links. [Type] Bug An existing feature does not function as intended labels Jan 24, 2020
@tellthemachines
Copy link
Contributor

Yep, that's what I'm suggesting. I think ellipses ... could work for now.

As for a holistic approach, I don't have anything fantastic. Maybe we break it similarly to how it breaks when editing the text?

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 😅

@noisysocks noisysocks added the Needs Dev Ready for, and needs developer efforts label Apr 1, 2020
@mapk
Copy link
Contributor

mapk commented Apr 14, 2020

@tellthemachines, let's try a simple CSS break-word for now. I'm not sure about a character limit. Translating a simple menu over to German gave me this.

Screen Shot 2020-04-13 at 7 56 37 PM

The longest German word, Dienstleistungen, is 13 characters. So let's go with that?

@github-actions github-actions bot added the [Status] In Progress Tracking issues with work in progress label Apr 16, 2020
@talldan talldan added [Block] Navigation Affects the Navigation Block and removed [Feature] List View Menu item in the top toolbar to select blocks from a list of links. labels Jul 23, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Block] Navigation Affects the Navigation Block Needs Dev Ready for, and needs developer efforts [Status] In Progress Tracking issues with work in progress [Type] Bug An existing feature does not function as intended
Projects
None yet
Development

Successfully merging a pull request may close this issue.

8 participants