Skip to content
This repository has been archived by the owner on Jan 26, 2022. It is now read-only.

Header Patterns: Followup Fixes #89

Closed
1 of 10 tasks
kjellr opened this issue Oct 12, 2021 · 4 comments
Closed
1 of 10 tasks

Header Patterns: Followup Fixes #89

kjellr opened this issue Oct 12, 2021 · 4 comments

Comments

@kjellr
Copy link
Collaborator

kjellr commented Oct 12, 2021

Following up from #74, there are a few header patterns with unfortunate responsive behavior. I'm creating this issue so that we can continue to track the issues:

Header with Tagline

  • This wraps poorly on small screens. (Screenshot)

Text-only Header with Tagline

  • This wraps poorly on small screens. (Screenshot)

Text-only Header with Tagline and all-caps Title

  • This wraps poorly on small screens. (Screenshot)

Header with centered Logo

  • This wraps poorly on small screens. (GIF)

Header with centered Logo in Navigation

  • The site logo disappears on smaller screens. (Screenshot)
  • The layout of the expanded menu looks weird. (Screenshot)
  • Depending on the number/length of menu items, the logo is not necessarily located in the exact center. (Screenshot)

Centered title with Navigation and Social Links Header

  • The items wrap oddly on small screens. (Screenshot)
  • The navigation items start stacking in a weird way on medium breakpoints. (Screenshot)

Title and Button Header

@kjellr kjellr changed the title Header Patterns: Responsive Issues Header Patterns: Followup Fixes Oct 12, 2021
@kjellr kjellr added this to the Beta 1 milestone Oct 12, 2021
@kjellr
Copy link
Collaborator Author

kjellr commented Nov 2, 2021

This wraps poorly on small screens

^ Regarding all of these bugs: Now that we've gone through all the trouble of getting WordPress/gutenberg#36003 merged, I'm finding more use cases where these look better without that control. For example, take this example with a bunch of menu items and a long tagline.

Here is is normally:

Desktop Mobile
Screen Shot 2021-11-02 at 3 54 16 PM Screen Shot 2021-11-02 at 4 10 33 PM

And here it is with flex-wrap disabled:

Desktop Mobile
Screen Shot 2021-11-02 at 3 55 17 PM Screen Shot 2021-11-02 at 4 10 46 PM

The second option here looks better on mobile, but way worse on desktop. I'm feeling a bit foolish here because I can't find a single example where the flex-wrap control "just works" across all breakpoints and makes these more robust.

It looked promising initially, and solved some of the mobile issues, but it creates more issues on desktop than I think it's worth. I think we might end up being better off without using it? 😕

cc @jasmussen, would you mind trying this out a bit too? I'm interested in your opinion.

@jasmussen
Copy link

Took it for a spin, and for simple short cases, things look good with and without. This one wraps:
before

This one doesn't wrap:

after

It's when the flex containers grow very big that the problems appear. This is with wrappig disallowed:
Screenshot 2021-11-03 at 09 44 09

This is with wrapping allowed (the previous default right?)
Screenshot 2021-11-03 at 09 44 18

In that particular case, the latter is better.

It's tricky, because on one hand, the fact that you can toggle between those options is in and of itself an argument for having the control, to be able to pick what works best. On the other hand, it's going to be hard for anyone but webdesigners to intuit that allowing or disallowing wrapping is going to be the problem solver in either case.

Which means we might want to look at increasing our confidence level that the control as we added it actually does benefit at least some patterns — that there are some designs we couldn't have accomplished otherwise. If we can find those, we can probably keep the control and manage its prominence by hiding the control in the tools panel.

Otherwise, we might want to revert the control to simplify things, and start to think of other ways to let those layouts have built-in intrinsic responsiveness. For example, the grid based behaviors outlined here might could potentially be enabled by default for blocks that have layout. What do you think? I do realize that would recast this as a future feature — but given the beautiful patterns you've built work well today, and would work even better in the future, that might be fine?

@kjellr
Copy link
Collaborator Author

kjellr commented Nov 4, 2021

Which means we might want to look at increasing our confidence level that the control as we added it actually does benefit at least some patterns — that there are some designs we couldn't have accomplished otherwise. If we can find those, we can probably keep the control and manage its prominence by hiding the control in the tools panel.

I spent a bit of time thinking about this, and I believe you've found one of those examples already:

This will be great for many sites, and wouldn't be possible without the control. I'm still undecided about whether or not we should use it for our patterns here, but I do feel that the tool has worth. That's good enough for the 11.9 feature freeze, and we can reconsider its appearance in the UI later on in the betas if we feel strongly about it.

@kjellr
Copy link
Collaborator Author

kjellr commented Jan 24, 2022

I'm going to close this one for now. If there are specific issues with these patterns to address, we can open up new individual Trac issues. Thanks!

@kjellr kjellr closed this as completed Jan 24, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants