Placeholder Text in input field not fully visible

[Presskopp]

Example is the color picker in Customizer (using Twenty Seventeen)

The fiels shows "Hex Valu" (more or less in different browsers).

This seems to come from

 .wp-picker-container input[type="text"].wp-color-picker {
	width: 65px; 

in \wp-admin\css\color-picker.css, L.102

[pento]

Thanks for the bug report, @Presskopp! I can see the same behaviour.

The width value causing this was introduced in [26435].

[stormrockwell]

fixed width, added padding for responsive issue, added wp-picker-clear css to fix responsive issues

[stormrockwell]

same as previous patch but better styling for the clear button

[stormrockwell]

photo of the 39096.2 patch

[karmatosed]

This fix looks good, but I do wonder if we need a more flexible solution for translation going forward? It does fix the initial issue though.

[Presskopp]

The string is longer in some languages, yes.

Example: Хексадекадна вредност (Macedonian)

[westonruter]

Instead of the placeholder being a label, what about a sample value? Like #21759b…? Then it won't vary by language and it would give users a cue to what the thing is that they should be entering there. Users may not even know what a “hex color” is, but they would probably recognize #21759b as some color code thing.

[Presskopp]

1) thinking about what @westonruter proposed
2) made a new patch
3) waiting for feedback

[tejas5989]

I have added the patch with the two changes regarding the Design and the color Hexa sample code. I have also attached screenshot for your review.

[afercia]

Replying to westonruter:

Instead of the placeholder being a label, what about a sample value? Like #21759b…?

I'd totally second this, since placeholders should not be used as replacements for field labels. ​From the specs:

The placeholder attribute represents a short hint (a word or short phrase) intended to aid the user with data entry when the control has no value. A hint could be a sample value or a brief description of the expected format.
...
Note: Use of the placeholder attribute as a replacement for a label can reduce the accessibility and usability of the control ...

Other references:

​Nielsen Norman Group: Placeholders in Form Fields Are Harmful

​The Paciello Group: HTML5 Accessibility Chops: the placeholder attribute

​Roger Johansson: The HTML5 placeholder attribute is not a substitute for the label element

[westonruter]

So what is the best sample value for a placeholder? Perhaps having a full value like #21759b would be misleading. What about #FF0... or something that makes it clear that it is not supplied yet. I can imagine someone who is new to computers might interpret a grayed-out placeholder value as just a regular value being already supplied or that the input is disabled.

[afercia]

Replying to westonruter:

So what is the best sample value for a placeholder? Perhaps having a full value like #21759b would be misleading. What about #FF0... or something that makes it clear that it is not supplied yet.

Yep, that would be ideal. Not sure about the best sample though. Maybe #addc01? :) Seriously, sometimes the hex format is represented as #RRGGBB but I guess that would be a bit too technical for users.

[westonruter]

@afercia I meant to actually include the ellipsis in the placeholder. Also, R and G are not valid hexadecimal numbers which range 0-F :)

[afercia]

@westonruter I know it's not a valid value :) I meant sometimes the format is represented in that way because RRGGBB represent the red, green and blue components of the color. In the same way, when we use dd/mm/yyyy that's not a valid value, but it represents the date format.

[westonruter]

@afercia So maybe #RGB… would be a good placeholder?

[afercia]

Replying to westonruter:

@afercia So maybe #RGB… would be a good placeholder?

Hm not sure :) That could be a bit misleading, it made me immediately think to the rgb format.

[SergeyBiryukov]

If we know the current/default color (the screenshot suggests that we do), can we use its HEX value as a placeholder, instead of some random value?

[westonruter]

@SergeyBiryukov good point. The control does have a defaultValue parameter that is obtained from the setting's default. See 39096.4.diff​.

[westonruter]

There is a chance that the underlying setting associated with the control would lack a default being defined, and in that case no placeholder would be shown.

[SergeyBiryukov]

Replying to westonruter:

There is a chance that the underlying setting associated with the control would lack a default being defined, and in that case no placeholder would be shown.

That's what I got when testing 39096.4.diff​ on trunk with Twenty Seventeen :)

[melchoyce]

Replying to SergeyBiryukov:

If we know the current/default color (the screenshot suggests that we do), can we use its HEX value as a placeholder, instead of some random value?

+1.

There is a chance that the underlying setting associated with the control would lack a default being defined, and in that case no placeholder would be shown.

Is this because a theme or plugin might not define a default, or something else? In that case, could we show something more obviously a placeholder? Like: ex: #ff0000 (Specifically using "ex:" here to say "this is an example, not a real value")

[joyously]

I like that ex: #ff00bb kind of thing, as long as that makes sense in other languages.
If not that, I think the #RRGGBB is very useful, even though it's English words that those are initial letters for.
This ticket doesn't take into account that the color picker is very limited in that it only accepts hex values, and no alpha, and no color keywords. These enhancements could come along and then this placeholder is moot.

[westonruter]

Replying to melchoyce:

Is this because a theme or plugin might not define a default, or something else?

That's right, as @SergeyBiryukov found in 21.

Replying to joyously:

I like that ex: #ff00bb kind of thing, as long as that makes sense in other languages.

That's my concern, that ex: or e.g. wouldn't have a short abbreviation in other languages.

If not that, I think the #RRGGBB is very useful, even though it's English words that those are initial letters for.
This ticket doesn't take into account that the color picker is very limited in that it only accepts hex values, and no alpha, and no color keywords. These enhancements could come along and then this placeholder is moot.

I think #RRGGBB is probably the best fallback placeholder text, even if R and G are not valid hex digits, as it's a placeholder not a default value to be re-used.

[westonruter]

Ok, 39096.5.diff​ implements default #RRGGBB. Give it a shake and I'll commit.

[sagarprajapati]

Hi @westonruter

I have checked your latest patch it is working fine on desktop device but it is not working on mobile devices. I have updated the patch and it's working on mobile devices as well as desktop devices. Please review it.

Thanks

[mayurk]

Hi @westonruter , @sagarprajapati , @swissspidy

I have checked latest patch https://core.trac.wordpress.org/attachment/ticket/39096/39096.4.patch and it's working on desktop browsers (chrome, safari, firefox) as well as mobile devices (iPhone 5, iPhone 6).

I have attached some images for review. Please check it.

​http://i.imgur.com/vP3HRD0.png
​http://i.imgur.com/dvlNxQ0.png
​http://i.imgur.com/kc0JLxT.png
​http://i.imgur.com/RmQ7cUy.png
​http://i.imgur.com/MS7QQ3e.png

Thanks

[westonruter]

In 40471:

Customize: Use fixed-width illustrative placeholder for hex field in color picker to prevent truncation.

Props stormrockwell, sagarprajapati, Presskopp, afercia, tejas5989, westonruter, mayurk for testing.
Fixes #39096.

[westonruter]

Re-opening for consideration in 4.7.5

[westonruter]

Closing since in trunk.

[afercia]

Seems to me a couple of CSS rules introduced here break the responsiveness of the input field. In the responsive view, it should become a bit bigger (as the button does). Instead now it looks like this:

Not sure this is really needed:

	.wp-picker-container input[type="text"].wp-color-picker {
		margin-right: 6px;
		padding: 3px 5px;
	}

I'm going to fix this in the refreshed patch for #39662. Please ping me if I'm missing something.

[afercia]

OK I realize now the left and right padding are necessary, but they should be adjusted and top and bottom not changed.

[westonruter]

@afercia Would you open a new ticket with a patch?

[westonruter]

@afercia or I suppose the fix can just be added as part of #39662.

[afercia]

@westonruter

I'm going to fix this in the refreshed patch for #39662.