Make title behaviours consistent across all widgets on first load

[karmatosed]

On first load the word 'Archives' outputs as the Widget title but it doesn't appear in the input field. If there is a default text, perhaps it should show. This could also assist by users making the connection with the words and where they can edit.

For example:

Another example, the Calendar widget has no title and compared to the examples above this feels weird. What I think should happen is that the same title behaviour occurs for all widgets when you first load them.

[westonruter]

@karmatosed what do you think about updating each widget to have a placeholder in each of their “Title” inputs if there is a default title that gets rendered in the preview? This would be a quick win.

Another example, the Calendar widget has no title and compared to the examples above this feels weird. What I think should happen is that the same title behaviour occurs for all widgets when you first load them.

In this case the placeholder would probably have to remain absent from the calendar widget, since there is no default widget heading. I don't think we'd be able to start introducing “Calendar” as a default widget title as this would be a backwards-incompatible change, such as for users who may be expecting the calendar widget to not have a heading when none is supplied. Does that make sense?

Aside: Placeholders were implemented for core widgets in the ​JS Widgets feature plugin.

[karmatosed]

Replying to westonruter:

@karmatosed what do you think about updating each widget to have a placeholder in each of their “Title” inputs if there is a default title that gets rendered in the preview? This would be a quick win.

Quick wins are 👍 I agree in hindsight lets not add a backwards-incompatible change.

[westonruter]

Ready for dev. Patch would include whatever the default titles are as found in WP_*_Widget::widget() methods to be added to the title input placeholder in the correspondingWP_*_Widget::form() methods.

[bor0]

Added diff that implements the proposed behaviour.

[dlh]

@bor0 Your patch updates the various widget() methods, but I think the form() methods are what need updating? 39909.2.patch​ has an example of what I understood the intent to be.

[westonruter]

@dlh you are correct. 39909.2.patch​ is the direction to take.

[bor0]

I see, thanks for the explanation! Added new patch that does that. I only updated widgets for which it made sense, i.e. widgets that also show their title by default.

Some examples that show their title (added placeholder): Archives, Categories, etc.
Some examples that don't show their title (didn't add placeholder): Text, Search, Calendar, etc.

[westonruter]

@bor0 a couple points about 39909.3.patch​:

• The esc_attr_e() function, like the other translation functions, should not be passed a variable but rather a string. If you want to pass a variable, like $this->name, you should use echo esc_attr( $this->name ).
• I'm not sure that it is right to print $this->name. I believe it should copy the string literal from the widget's widget method as @dlh showed in 39909.2.patch​.
• The change to class-wp-widget-tag-cloud.php is using a printing function in string concatenation, so that won't have the desired result.

[bor0]

@westonruter can quickly fix 1 and 3, but I'm wondering about 2. Shouldn't we change the widget method to use $this->name instead to keep consistency? In this case, it looks like we're repeating the same string 3 times (__construct, widget, form) which feels kind of weird.

[dlh]

The name property is documented as the "Name for the widget displayed on the configuration page." I took it to be only a coincidence that it was the same string as the default title.

Perhaps the duplication speaks to the need for something like a default_title property or $widget_options key? But, if so, I don't know whether that would be in-scope for this ticket.

[bor0]

I agree about the scope changes part. If necessary, another ticket can be filed to take care of that.

[westonruter]

@bor0 small change, but _e() in these cases should actually be esc_attr_e() to ensure the translated string gets escaped for an HTML attribute context.

[bor0]

Ah :) figured to use _e because we're using string literals but if that string changes in the future it can be an issue potentially. Submitting another patch in a few.

[westonruter]

@bor0 the problem isn't with the English string in core, but rather if the translated string from another language could potentially a character that would need to be escaped.

[bor0]

Ah. Good point. Thanks for the explanation!

[bor0]

@westonruter, I was searching for other appearances like that, and I found:

https://core.trac.wordpress.org/browser/trunk/src/wp-content/themes/twentyseventeen/footer.php#L25
https://core.trac.wordpress.org/browser/trunk/src/wp-content/themes/twentyseventeen/template-parts/navigation/navigation-top.php#L12

Do you think we should fix them as part of this ticket, or create another ticket for that?

[westonruter]

​https://github.com/xwp/wordpress-develop/pull/218

[westonruter]

@bor0 I added a couple more placeholders for dynamic defaults in ​9126af5.

@karmatosed thoughts on title-placeholders.mov​?

[karmatosed]

@westonruter, looks good to me!

[westonruter]

In 40251:

Customize: Show title input placeholders for widgets that have default titles when rendered.

Fixes #39909.
Props bor0, dlh, westonruter.

[westonruter]

Re-opening for consideration in 4.7.4

[afercia]

We've discussed a bit this change during today's accessibility meeting, and we wouldn't recommend to use the placeholder attribute for this purpose.

​According to the spec, the placeholder attribute should be used to:

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

Also, from a usability point of view, this change visually matches the placeholder with the widget title shown in the Customzer preview, but in the Widget screen doesn't help so much.

Since we're dealing with the default value, wouldn't be better to populate the field with the default value instead of using it as placeholder?

Adding an a11y-placeholder keyword since we're planning to use it for other cases related to placeholders.

Please, for any UI important change or changes to interactive controls, form fields, and so on, please always set the "accessibility" focus. 🙂

[flixos90]

I agree with @afercia here that providing the default values as actual values instead of placeholders would make more sense. It is not only better for accessibility, but they are actual values, not placeholders.

We could either show them initially (true default values), or we could consider to show them anytime the field is empty (also on subsequent actions of emptying a title). The latter would be a bit confusing, on the other hand the field being empty while the title shows up in the frontend doesn't make much sense.

Also given @swissspidy's comment in today's bug scrub, this ticket might not be significant enough to include it in 4.7.4.

[westonruter]

So how should we resolve this? Should the placeholder be moved to value? This would mean that the initial widget title in the widget in the preview will match the initial value in the title field when a widget is added, but if the user then empties out the field that value will actually still appear to persist, which would confuse users. To me it seems the placeholder would be less confusing in that regard.

[westonruter]

Something else that I realized is that the placeholder or default value would need to be obtained with the frontend locale active. Currently it is using the admin locale, and so this could lead to an unexpected value shown if the admin and frontend have different locales.

And if we're not using placeholder either, it seems we need to revert this and revisit in the future. Nevertheless, the placeholder still seems like a better user experience (as opposed to default values) and reflective of the behavior of the behavior for an empty title on the frontend since they cannot be emptied.

@afercia @flixos90 @karmatosed so, revert or amend?

[westonruter]

In 40806:

Widgets: Revert [40251] pending more accessible solution for showing default widget titles rather than using placeholders.

See #39909.