Make the search block editor match the frontend #30176
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
youknowriad
added
[Type] Enhancement
youknowriad
requested review from
scruffian,
aristath,
jasmussen,
ellatrix and
carolinan
youknowriad
commented
Mar 24, 2021
| // This rule only makes sense for UI not blocks. | ||
| // eslint-disable-next-line react/forbid-elements | ||
| <button type="submit" className="wp-block-search__button"> | ||
| <RichText |
There was a problem hiding this comment.
It seems there's something that prevents RichText from working as a "button". I've used a small hack here to make it work and still keep a similar markup to the frontend.
There was a problem hiding this comment.
What prevents it from working? Do you get any errors?
There was a problem hiding this comment.
It's just stuck, like you can't edit it. Maybe "contenteditable" doesn't work on buttons?
There was a problem hiding this comment.
That's interesting. I'll try this out in a bit.
There was a problem hiding this comment.
It should work: https://codepen.io/iseulde/pen/vYgOpVw
Maybe something is wrong in RichText.
There was a problem hiding this comment.
For some reason the selection change event is not firing in this context. It is in codepen though. Strange.
There was a problem hiding this comment.
It seems something is the block editor is causing the issue. I insert <button contenteditable>test</button> without rich text in a block and it also fails to set selection. The same line on an empty web page works fine.
There was a problem hiding this comment.
@ellatrix after the removal of revert: all, I have two bugs:
- In safari, backspace removes the block and not a character in the text
- in chrome, I can't type an empty space
There was a problem hiding this comment.
Hm, yes, Space will conflict with "pressing" the button.
I'll have a look at both issues. In the meantime, feel free to nest it in a span and we can adjust later.
|
Size Change: -37 B (0%) Total Size: 1.41 MB
ℹ️ View Unchanged
|
This was referenced Mar 24, 2021
ellatrix
reviewed
Mar 24, 2021
| textarea, | ||
| button { | ||
| font-family: system-ui; | ||
| all: revert; |
There was a problem hiding this comment.
Just for the public record :) all: revert; is also reverting -webkit-user-modify to read-only preventing contenteditable from working.
7 tasks
|
Empty theme, editor: Front: Broken styles in Twenty Twenty One, front view After: As with the select list, I would like the defaults to be more usable, they need to be good enough to use as is without forcing theme and plugin developers to add their custom styles. |
I agree with this but I don't think it should be done in these PRs because it has implications and impact on themes which can be higher and it should be done very carefully. For now, the purpose is just to make the backend look like the frontend without impacting the frontend. I'll fix 2021 |
youknowriad
force-pushed
the
update/search-block-front-parity
branch
from
bb005ae to
2385eff
Compare
|
I really appreciate this PR. I just ran into issues where the use of editor components adds some extra classes and therefore specificity to the rules, which means it's really really tricky for a theme to style the form widgets of this one in an elegant way. It's specifically the
and on the frontend:
And here's after, in the editor:
and on the frontend:
In other words, to me this solves a problem of the style inheritance very nicely. |
|
Yes, this is a good PR. Unfortunately, the reset used here conflicts with placeholder buttons. It's the same issue we have with themes styling |
|
Closing this as still blocked by CSS bleed in placeholder components. It's unclear how we'll solve this. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Related #29976
This block also relies on "input" and "button" element which in wp-admin has some opinionated styles, this PR resets those styles in the editor canvas.
This PR needs to be tested properly (specially the editor UI to ensure the select reset is not affecting anything that shouldn't).
At the moment, this PR impact placeholders in other blocks because these resets have higher specificity than the UI components used in placeholders (Button, TextControl...). We have three options:
Use a similar technique as in Editor Styles: Add a transform for button rules #29229 and add:not(.components-button)and similar to the resets.