Forms: use a placeholder attribute in the editor instead of value - #41712
Conversation
|
Are you an Automattician? Please test your changes on all WordPress.com environments to help mitigate accidental explosions.
Interested in more tips and information?
|
|
Thank you for your PR! When contributing to Jetpack, we have a few suggestions that can help us test and review your patch:
This comment will be updated as you work on your PR and make changes. If you think that some of those checks are not needed for your PR, please explain why you think so. Thanks for cooperation 🤖 The e2e test report can be found here. Please note that it can take a few minutes after the e2e tests checks are complete for the report to be available. Follow this PR Review Process:
If you have questions about anything, reach out in #jetpack-developers for guidance! |
Code Coverage SummaryThis PR did not change code coverage! That could be good or bad, depending on the situation. Everything covered before, and still is? Great! Nothing was covered before? Not so great. 🤷 |
|
@simison Does this work as expected for you in any text input field? |
|
works ok for me
what do you mean? 😆 |
|
I see what @enejb is talking about. With this PR loaded, I can add placeholder text as expected in the sidebar. But if I try to type placeholder text directly into the input in the main part of the block editor, it always deletes all but the last character I typed. I also confirmed this does not happen on trunk. I'm sure it's just some mix-up of state - basically since we changed the relationship between value and placeholder, we don't track value properly when typing into the input. |
|
Weird, that's the scenario that worked for me just fine, but I'll do further testing 👍 Might be browser dependant. |
|
Just to be sure we're talking and seeing the same thing, here's a video of the behavior. I type first in the placholder field in the sidebar (works), and then directly in the input. I've also confirmed that that if I keep value = { placeholder } like below, the issue is resolved input-placeholder.mp4 |
Thanks! It might make sense to retain |
|
I think we're trying to mix two different concepts in general:
And that was actually quite confusing for me when I first interacted with the blocks. When I started typing I thought that would be a default value.. If I'm not wrong the input fields have a prop That would require some design input too to try to ensure that it's clear when typing in an input, it's the default value. A placeholder of course like |
f0212c6 to
f2481f9
Compare
Code Coverage SummaryThis PR did not change code coverage! That could be good or bad, depending on the situation. Everything covered before, and still is? Great! Nothing was covered before? Not so great. 🤷 |
f2481f9 to
0ca873f
Compare
| style={ fieldStyle } | ||
| type={ type } | ||
| value={ placeholder } | ||
| type={ isSelected ? 'text' : type } |
edanzer
left a comment
There was a problem hiding this comment.
Tested text and number inputs. Works great.

Use a
placeholderattribute in the editor for placeholder text instead ofvalueattribute.By using
value, we have a couple issues.When theme includes styling for
::placeholderpseudo element, we don't show it. Consider for example CSS:Before
After
When we add a number input, its
type="number"disallows non-numericvalue, even ifplaceholdercould be numeric. We would only need to support numeric placeholders for that input. We could change that field totype="text"in the editor, but that would miss out browser number controls, any styling applied to number fields, and otherwise also mismatch what they see in the editor with frontend.Before
After
Proposed changes:
placeholderattribute in the editor for placeholder text instead ofvalueattribute.valueattribute for entering the placeholder value while block is focusedOther information:
Jetpack product discussion
Does this pull request change what data or activity we track or use?
Testing instructions: