Improve color contrast of the default block inserter shortcuts.

[afercia]

As mentioned in #10519 (comment) the default appender shortcuts icons and the default block shortcuts icons are styled differently.

In the default appender, the shortcuts do have a sufficient color contrast:

However, when the default appender is clicked, it becomes the "default block" and the icons don't have a sufficient color contrast:

This small PR seeks to improve the contrast and simplify the CSS:

• removes specific styling from the default-block-appender
• uses the colors removed from the default-block-appender directly into the inserter-with-shortcuts, as part of its default styling

Worth noting there are also some CSS rules related to the opacity transition that don't work as expected after #12510. I guess this should be addressed separately together with the refactoring proposed in #10519.

[jasmussen]

Thanks for the PR and ping. Given that we mean to retire those, is it actually worth making this change? The question here is not one of whether one is better than the other, rather: which WordPress release will this ship with? If it's 5.1 then I would be disappointed if we couldn't fix the problems with this interface at the root, in #10519.

So expanding this for a wider review from the group.

[afercia]

Yup, totally agree it depends on when the refactoring will happen. If it's going to happen soon, in the next release, I'd agree to just close this PR. Otherwise, I'd like to temporarily fix the contrast issue. Thank you.

[tofumatt]

Personally I too would like to see these retired. Leaving them with bad contrast on focus isn't a friendly message to users who have trouble with low contrast, but realistically I don't want them to be visible at all so I'd say they're getting a better deal 😉

I think making them more obvious here isn't a good stopgap because it's a worse visual UX for users who can already make out the icons. I know that's not a great answer but I think it's better to leave them as-is until we remove. If someone made a PR that just removed them though I'd approve it ASAP 😄

[afercia]

Looks like #10519 / #11329 won't make it for 5.1. Can we improve this color contrast in the meantime? /Cc @jasmussen @tofumatt

[jasmussen]

Can we improve this color contrast in the meantime?

Yes, I think we should. Because current master isn't great. Here's 5.0.3:

Notice how the contrast is sufficient in the initial placeholder, but it is not sufficient in an "empty paragraph placeholder".

Here's this branch:

So outside of the contrast changes for the empty paragraph, at least this branch also makes it consistent.

However, the fade effect is missing from the left plus on a new post, and it's also missing from the shortcuts on the right. That's not new to this branch specifically, but seems worth fixing while we're at it:

In other words: can we make it so all the shortcut icons in placeholders fade in, whether in the initial appender, or the empty placeholders? If yes, then I think we can ship this as a good interim improvement.

[afercia]

However, the fade effect is missing

@tofumatt see my previous comment:

Worth noting there are also some CSS rules related to the opacity transition that don't work as expected after #12510. I guess this should be addressed separately together with the refactoring proposed in #10519.

Those are now rendered only when hovered. So when rendered, they're already hovered and there's no state transition the CSS transition can understand.

[jasmussen]

Those are now rendered only when hovered. So when rendered, they're already hovered and there's no state transition the CSS transition can understand.

I'm not sure that's true. I believe that animation-fill-mode: forwards; should enable this, and this is also the case for the block mover which doesn't exist in the dom until you move the cursor near them.

But it's not the end of the world to ship this without those improvements, just seems like it might be worth it. Though it's worth noting that the fade effect is missing on the empty paragraph placeholder in this branch, but it is present in master.

[afercia]

animation-fill-mode: forwards; applies to keyframe animations. Here, the opacity property uses a CSS transition. We can try to replace it with the keyframe one.

[afercia]

Though it's worth noting that the fade effect is missing on the empty paragraph placeholder in this branch, but it is present in master.

Check better 🙂 This PR touches only colors.

[jasmussen]

🤦‍♂️

I blame mondays.

Anyway, no objections to getting this in, as it adds a little consistency. Would be nice if we could restore the fading.

[jasmussen]

CC: @youknowriad

[afercia]

Yep, I'm looking into it.

[afercia]

Even the most simple things... 🙂 turns out the effects can only work consistently if the elements have the same rendering logic.

Basically when an element is always rendered in the DOM, it can get both fade-in and fade-out effects.

Instead, when an element is added to the DOM, it can get the fade-in effect via the keyframe animation but when removed it's just removed... there's no time for transitions or animations. To have a fed-out effect, either the element should always be rendered or we should detect transitionEnd or animationEnd and then remove it. Meh.

In the last commit:

editor-default-block-appender:

• the "plus" button is always in the DOM: can have fade-in and fade-out with CSS transition
• the "shortcuts icons" are rendered / removed: can only have fade-in
• I've added the fade-in animation on the "shortcuts icons", it was missing

side-inserter and empty-block-inserter:

• they're always rendered and removed when typing / emptying the block; question: @youknowriad any performance concern here?
• can only have fade-in
• I've changed the CSS from transition to animation

Going to check if the side-inserter "plus" can be changed to always be rendered in the DOM.

[tofumatt]

I didn't think it was worth investing in improving these** as my impression was that they're be removed. I don't think they're a good UX regardless of their accessibility.

I'd rather they just be removed.

That said, seems the inserter UX is changing in #10519 so I'm fine with this as a stop-gap.

[afercia]

I'd rather they just be removed.

Looking forward for that to happen but, as commented above, looks like #10519 / #11329 won't make it for 5.1.

I'm fine with this as a stop-gap.

I can't express how this kind of self-referential language ("I") isn't helpful.