-
Notifications
You must be signed in to change notification settings - Fork 4.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Writing Flow: Always add an empty at the end of the block list #3623
Conversation
Codecov Report
@@ Coverage Diff @@
## master #3623 +/- ##
==========================================
- Coverage 36.95% 36.69% -0.26%
==========================================
Files 268 268
Lines 6673 6649 -24
Branches 1202 1201 -1
==========================================
- Hits 2466 2440 -26
- Misses 3555 3557 +2
Partials 652 652
Continue to review full report at Codecov.
|
I really, really really love this. I think it's a much better experience without all that trailing chrome, and it's a much clearer way to insert content after non-text blocks. Here's a brief GIF: I'd love @mtias and @karmatosed's opinion (but I'm crossing my fingers they'll like this as much as I do), and we want to make sure that empty textarea is announced correctly to screen readers (cc: @afercia for a quick test perhaps). Finally it looks like we may in fact need #3485 after all (despite my comment here). |
Small update — we'll still want the placeholder to look and function like it used to on an empty post: That is — with the "Write your story" prompt, and the border on hover. The chief reason why the border and text prompt shown at the end of the blocklist on a populated page should be less visible, only indicated by the hover ibeam cursor, is that there isn't actually a block there. I know that's the same at the start of a post, but we do need a prompt and some canvas indication there. |
Updated with the visible placeholder when post is empty |
Tested a bit with keyboard only and also with screen readers. Seems the block is announced correctly, as it just uses the default aria-label However, there's a big issue 🙂 Right now, it's a keyboard trap. Whatever I do, using only the keyboard with no screen reader running or also with a screen reader, when I tab away from the lazt block I always get a new paragraph and there's no escape. This breaks any attempt to navigate the page using the keyboard. At each Tab press, a new paragraph gets added: Also, the paragraphs get saved in the content that soon becomes full of empty paragraphs:
|
@afercia What solution do you propose to this? The only option I can think of is making this "untabbable" when the post is not empty which make it useless using keyboard but I think it's more targeted towards mouse users? |
Edit: Actually I may have a better option, transform this placeholder to a "button" only actionable on click/enter |
Forgive me for asking a possibly silly question: why does tabbing away from the placeholder textarea create a block? Shouldn't it just focus whatever element comes next in the flow after the placeholder? |
updated, there's no tab trap anymore but I may be missing some ARIA labels |
If a button is kosher to use and that works well, then cool — but a followup question: is it then kosher to apply |
I also think from an usability perspective, there should be some indication when hovering that area. A possible problem is it kinds of overlap the "drop zone"? |
Tested with latest commit, there's no more a keyboard trap and that's good 🙂 However, when tabbing from the title to the first "Write your story" there's no indication of focus, so there's a tab stop but I don't know where I am. Instead, after I add something and tab again, all the following buttons have a light gray border to indicate focus: This is maybe too light and should be improved a bit but I guess it's outside of the scope of this PR. I'd second Joen: maybe the cursor should be a pointer but then maybe there should be some additional visual indication on hover. |
021ffe1
to
93a16f9
Compare
I think for mouse users the "text" cursor is a better visual indication than the "hover" style. The "hover" style on an empty area is distracting IMO.
This is fixed |
93a16f9
to
441cfc4
Compare
Possibly related to the "keep typing" thing: #3558 |
That's related to the fix for the tab trap, if you want to keep typing it should transform to a text block when it receives the focus. A middle ground would be to do so only for empty posts. What do you think? |
This sounds good to me. One feature that works in master is that if the image is the last block in the list, and you select it and press Enter, then you can start typing again. Not very discoverable which is why I really like this branch and approach. However can we retain the feature? That is, if you press enter on the last image in a blocklist, you can type? |
box-shadow: none; | ||
display: block; | ||
width: 100%; | ||
height: $text-editor-font-size * 6; // 1.5 times the height of an empty paragraph |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's worth considering to introduce new scss variable $empty-paragraph-height
to avoid those comments.
} | ||
|
||
appendDefaultBlock() { | ||
const newBlock = createBlock( getDefaultBlockName() ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it make sense to update createBlock
definition to simplify this call to:
export function createBlock( name = getDefaultBlockName(), blockAttributes = {} ) { ... }
this.props.onInsertBlock( createBlock() );
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't know :)
<div className={ className }> | ||
<BlockDropZone /> | ||
<button onClick={ this.appendDefaultBlock }> | ||
{ count === 0 && __( 'Write your story' ) } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice and simple 👍
} | ||
} | ||
|
||
export default connect( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it would be nice to have 3 unit tests:
- count > 0 (snapshot test)
- count = 1 check if there is class
is-visible-placeholder
andWrite your story
text - spy on
insertBlock
I can add them, just ping me :)
441cfc4
to
b8f960c
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I reviewed code part and it looks great. This change also removes some more complex logic which I'm always happy about. I will add unit tests for the newly introduced placeholder component. Don't wait for me, this is too nice change to postpone it :D
Sorry for not replying here earlier, but I think this is a bit rough and would need some further work and polish to be better than what we had, in my opinion. Empty paragraphs even if you don't write anything.If you click on the bottom of the post just to deselect something, you end up with an empty paragraph that you need to remove. This is not a great user experience. If you click the bottom area, and then click something else, no paragraph should be left. Jumpy ContainerWhen you click on the empty area, there is a foucs area that is larger than what the paragraph would end up being, so the visual border jumps after click: Preserving the PlusI think Medium's screenshot in the linked issue strikes a better balance. At the moment it's not clear you can add other stuff other than text. The I strongly suggest retaining the plus, maybe show it when hovering the bottom area, and remove it once you start typing. Treat it as if
|
Perhaps this PR was merged a bit quickly, but nothing's so bad that we can't fix it for 1.8 with a little polish here and there:
Those seem like good ones to address first. Treat it as if isEditing Continues and Preserving the plus could potentially be solved together, or at least dictate how they should be implemented. That is to say, right now the behavior of the trailing placeholder — the one at the end of a non empty post, not the first one on an empty post — is to create a new block when clicked/invoked. Given the model here is that of Medium, which I agree works very well, perhaps this trailing placeholder can be... let's call it "Schrödingers placeholder" — it exists, and doesn't exist, until you take an action on it. Imagine you have a post with just an image in it. It could then work like this:
Mockups. First you hover near the end: Then you click the "textfield", but no paragraph is created yet: If you start typing, that's when the paragraph is created: Edit: Updated the mockups above to have an image instead of text. Thoughts? @mtias @gziolo @youknowriad @karmatosed |
This was working and got broken in one of the last changes, I'll fix it.
That's not an easy thing to do, because when we click it's transformed to a text block and we'd have to remove empty text blocks at the end or something and it's not easy to know when to do this exactly.
Same, this is doable but may take some time because typing in a input should transform to a text block and keep the cursor at the right position. Maybe we should revert this PR and try to address those |
I was thinking it would be a "mode" of the paragraph block that initializes as Agree on reverting if we need more time to figure out implementation. |
readOnly | ||
onFocus={ this.appendDefaultBlock } | ||
onClick={ this.appendDefaultBlock } | ||
onKeyDown={ this.appendDefaultBlock } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In what case could a keydown
event occur without the block already being focused? (And therefore triggering the identical focus
event handler)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch, probably a useless event handler.
closes #3078
This PR