Try: Menu item placeholder inheritance. #32512
Conversation
|
I would encourage reviewers to give this PR a run and not just look at the GIFs. Here's a convenient Gutenberg-run URL: http://gutenberg.run/32512 To me, it feels much better in practice than it looks. The wavy underlines immediately stand out as "needing attention", and clicking them and being immediately met with a choice to rectify that, feels very natural. Here's some test content you can also start with: As a next step, I will try to explore better wavy underlines. I'd love to provide a lovely SVG, but make sure it inherits colors. |
|
Size Change: -324 B (0%) Total Size: 1.06 MB
ℹ️ View Unchanged
|
|
I found a way to make a prettier wavy underline in #32579, but alas it doesn't work with wrapping text. |
|
This one feels more natural to me than #32578. The wiggly underline might get confusing when combined with browser/OS grammar checks (since they often also impose an underline), however I'm not sure this would end up being applied to user-entered text, right? In the PR at least, it's only applied to block placeholders (which we control the text for). This could work if we had logic that would validate any links in a pattern to see it matched with an existing post/page on insert. If it did not, then Gutenberg could transform that block into a placeholder. So for example, a pattern could define a navigation block like this, and this is what would show up in the pattern preview:
But when a user inserted that pattern, it would show up like this:
The "Home Link" block would still work, since we can resolve that. But the other two pages would automatically revert to placeholders. Does that generally make sense? |
|
Thank you for looking, Kjell. While I'm starting here with the Navigation block because it has part of this setup state built, what I'm essentially looking for is a general design that we can use across all blocks, including Buttons and others. In other words, I want the design to work for this pattern as well:
Having slept a few days on the squiggly line, I'm also doubting it myself now. I'll keep thinking. But to answer your question, I think the preview and what you insert should be identical, give or take a few small additions. So in your examples, the Home, About and Contact would keep their labels. The only addition would be the squiggly line, point being we could apply the squiggly line to "Our Work" or "Where We Are" buttons as well. It could theoretically even work for a random link to The reason I think it's important to retain the pattern-definded text/labels is to both meet expectations you have when you see the pattern, but also to enable and encourage super opinionated patterns. Someone opening a pet store might look for a photo of a dog and clinic related labels in patterns. And while they can and should edit things, I think there's value there. |
Thanks for that example — that makes sense. |
jasmussen
force-pushed
the
try/menu-item-placeholder-inheritance
branch
2 times, most recently
from
3fa94e4
to
352ac86
Compare
|
Okay, I pushed some polish and some tweaks to this one. I improved the wavy underline, abstracted the way it's built, and added in opacity. I think it's working fairly well, and I genuinely think it's worth trying. Here's how it looks:
The color is inherited in the underline:
It'd be nice to explore a next step of letting the menu item stay in a placeholder state, even if the label has been filled out. That should be the key pattern enabler. |
jasmussen
force-pushed
the
try/menu-item-placeholder-inheritance
branch
2 times, most recently
from
a1dbeba
to
a938a9d
Compare
|
Rebased and tried this one again. I actually think it's worth trying, because it's mostly CSS. Here's a high res screenshot of a quickly cobbled together "pattern":
|
|
I'd really like to land this one. It removes more CSS than it adds, and and it allows menu items to inherit styles, which on its own is valuable too. If we find the wavy underline doesn't work, we can leverage the MacOS grammar style:
That would be an easy followup patch to do to this one. @kjellr or @georgeh got any green checkmarks lying around? |
| // Provide a little margin to show each placeholder as a separate unit. | ||
| margin: 2px; | ||
| // Appear disabled to indicate incompleteness. | ||
| opacity: 0.6; |
There was a problem hiding this comment.
I'm not sure this opacity effect is going to work if we apply it to the theme's colors. In Twenty Twenty for example, it results in text that doesn't pass AA contrast:
I expect this would be similar in any theme that uses a text color that isn't relatively high contrast by default. Do you think this works nicely if we remove the opacity effect?
There was a problem hiding this comment.
Good thought, I removed it for now. I think it might be worth to revisit this, or a variant of this, to indicate some form of "interactivity" that feels a bit lost without it. But I'd love to do that separately.
jasmussen
force-pushed
the
try/menu-item-placeholder-inheritance
branch
from
a938a9d
to
f5c7212
Compare
|
Thanks so much for looking. I'll and this and will always be happy to follow up. |
* Try: Menu item placeholder inheritance. * Simplify and polish the waviness. * Remove opacity.
Description
In #32373 we are discussing how the navigation block placeholder state can be improved. As part of the conversation, one idea is to de-emphasize the overall navigation block placeholder state — after all, navigation can contain both links, spacers, search, social links — and instead focus in the menu item placeholder state.
We already have one such, it looks like this:
This PR leverages that, but adds font, style and color inheritance, as well as a grammar-like wavy underline to indicate this item needs attention:
I'm not entirely happy with the style of the wavy underline, and I'm exploring better alternatives in this codepen. Nevertheless the benefit of doing it this way is that it inherits color, making it work well on other theme backgrounds. Here are two twenties:
Note, this PR is in a draft state because it is only an initial step at exploring the feasibility, the pros, and the cons of this appraoch. If we think there's potential — already in testing this branch, I'm rather convinced there is — it should be taken a few steps further:
Depending on our approach, we can potentially defer some of those changes, but they are nevertheless part of the idea.
How has this been tested?
Please insert a navigation block, start empty, and then insert page links or custom URLs or any other menu item links. But instead of choosing a page or pasting a URL in the dialog that follows, press Escape to close it.
Checklist:
*.native.jsfiles for terms that need renaming or removal).