Try: Improve columns block #11620
Try: Improve columns block #11620
Conversation
jasmussen
force-pushed
the
try/improve-columns
branch
2 times, most recently
from
5fbba12
to
cf82200
Compare
jasmussen
added
[Type] Enhancement
This PR aims to improve the column block usability, as well as fix a few issues: 1. It makes the individual columns unclickable by using pointer events. Since these are not actionable yet, being able to select them is not really helpful. 2. It improves the UI around reusable blocks, by fixing an issue where even though contents should be disabled when in a reusable block, it was still selectable if there were nested blocks. 3. It further improves the reusable block UI by fixing a regression where the reusable block editing bar did not push down content sufficiently. 4. It refactors how margins in the columns block work, to be simpler and more predictable, and makes it behave similar to every other block in that regard.
jasmussen
force-pushed
the
try/improve-columns
branch
from
cf82200
to
db30ce6
Compare
This is a solid improvement, far fewer blue boxes appearing.
Great! Feels much better, again!
Yes, it felt weird before to have the column selectable, the inner paragraph selectable, and the columns themselves selectable, and it was a matter of pixels movement to go from one to the other. Although I still need to use the block navigation to select the columns themselves, this PR makes things feel a lot better. I'll hold back from approving for now just because it's a change to the UX that I think should have a couple more eyes on, but it's a 👍 from me! |
|
I wish preventing individual columns from being clicked was handled via a Do we still have a ticket open for that "pass-through" concept? |
I believe it's this one: #7694 |
|
Pushed a fix for the empty columns, that further refactors. There's one thing left that I'd like to fix, and it's the "initial state". Hard to explain, so here's a GIF:
So, the pointer-event stuff I use as a half-way method to disable the column blocks, singular, doesn't take when the default appender is there. @aduth do you have bandwidth for a sanity check on this one? I think we can ship this as an iterative improvement even with that still in place, but it'd be a nicer experience if we could disable the column block even when it only contains the appender. |
| pointer-events: none; | ||
| } | ||
|
|
||
| :not(.components-disabled) > .wp-block-columns > .editor-inner-blocks > .editor-block-list__layout > [data-type="core/column"] > .editor-block-list__block-edit > .editor-inner-blocks { |
There was a problem hiding this comment.
Yep. Have to be careful with the pointer events! I look forward to when we have a more official passthrough method.
|
Thank you. I will let you merge if you feel it's good to go — I certainly think it is, though I would like to then address #11620 (comment) in a separate PR. Edit: Upon second thought, this adds much needed bugfixes and works well. I can enhance the initial hover issue separately. Merging. |
This PR is a followup to thoughts in #11620 (comment). It improves the columns block further by doing two things: 1. It hides the hover effect on the individual _column_ block in the initial state. 2. It changes the non-block "fake" appender to be a textarea instead of an input. To elaborate on 1, in #11620 we used pointer-events to disable the individual column blocks as selectable using the mouse. This is because those columns are not actionable at the moment, and in the current implementation of the column, being able to hover and select them only causes issues with selecting the parent columns block, which _is_ actionable. However pointer events was not enough for the _empty_ state of a columns block. In this state, the block features no inner blocks, except the individual column blocks, because no content has yet been inserted yet. In this state, you see the "appender", which is not actually a block even though it looks exactly the same as an empty paragraph. Because this is not technically a block, the deepest nested child is a _column_, which is then allowed to be hovered. In 1 I add a workaround to that, to simply visually hide the hover effect. I expect this to be refactored in a future columns update, but for the time being it makes it far more usable. To elaborate on 2, there has been a long time issue with the appender (again, not the block, the fake version that we use before an empty paragraph is inserted) wrapping text in translations. This is because text _cannot_ wrap in an `input` field, which the appender is. By changing this to a `textarea`, the text can wrap. This might affect themes which specify the input element for increased specificity in their editor styles, but overall it still seems like a worthwhile change to make, since it's the only way we can allow the writing prompt to wrap its text.
* Further improve columns block. This PR is a followup to thoughts in #11620 (comment). It improves the columns block further by doing two things: 1. It hides the hover effect on the individual _column_ block in the initial state. 2. It changes the non-block "fake" appender to be a textarea instead of an input. To elaborate on 1, in #11620 we used pointer-events to disable the individual column blocks as selectable using the mouse. This is because those columns are not actionable at the moment, and in the current implementation of the column, being able to hover and select them only causes issues with selecting the parent columns block, which _is_ actionable. However pointer events was not enough for the _empty_ state of a columns block. In this state, the block features no inner blocks, except the individual column blocks, because no content has yet been inserted yet. In this state, you see the "appender", which is not actually a block even though it looks exactly the same as an empty paragraph. Because this is not technically a block, the deepest nested child is a _column_, which is then allowed to be hovered. In 1 I add a workaround to that, to simply visually hide the hover effect. I expect this to be refactored in a future columns update, but for the time being it makes it far more usable. To elaborate on 2, there has been a long time issue with the appender (again, not the block, the fake version that we use before an empty paragraph is inserted) wrapping text in translations. This is because text _cannot_ wrap in an `input` field, which the appender is. By changing this to a `textarea`, the text can wrap. This might affect themes which specify the input element for increased specificity in their editor styles, but overall it still seems like a worthwhile change to make, since it's the only way we can allow the writing prompt to wrap its text. * Fix by using TextareaAutosize. Props @aduth. Also adds resize: none;, props @chrisvanpatten. * Fix unit tests
This PR aims to improve the column block usability, as well as fix a few issues:
It makes the individual columns unclickable by using pointer events. Since these are not actionable yet, being able to select them is not really helpful.
It improves the UI around reusable blocks, by fixing an issue where even though contents should be disabled when in a reusable block, it was still selectable if there were nested blocks.
It further improves the reusable block UI by fixing a regression where the reusable block editing bar did not push down content sufficiently.
It refactors how margins in the columns block work, to be simpler and more predictable, and makes it behave similar to every other block in that regard.
JIFs
How reusable blocks work now:
Previously there wasn't enough margin below the gray bar, and the "Save" button was hard to click.
Columns:
Previously you could select individual columns, but these columns were not actionable. This PR makes them unclickable.
As part of phase 2, I expect we will continue to iterate the UI for selecting blocks, notably in nested contexts, and as part of that we can consider making the individual columns selectable again. But for now, this seems like a good solution.
Please share your thoughts.