WordPress.org

Make WordPress Core

Opened 21 months ago

Closed 4 months ago

Last modified 3 months ago

#42390 closed defect (bug) (fixed)

TinyMCE + Edge input:focus placeholders disappear

Reported by: Cybr Owned by: anevins
Milestone: 5.2 Priority: normal
Severity: normal Version: 4.9
Component: Administration Keywords: has-patch has-ui-feedback has-screenshots commit
Focuses: ui, accessibility, javascript Cc:

Description

Using EdgeHTML 15, when the TinyMCE script is present (tinymce.min.js), input placeholders disappear when focussing the field.

A good place to test this behavior is on the post/page's title input, where "Enter title here" will disappear on focus.

AFAIK, only input[type=text] and textarea are affected.
input[type=password], for example, works as intended.

Attachments (2)

42390.patch (4.7 KB) - added by Cheffheid 20 months ago.
Leaves label hidden with sr-text class, adds placeholder attributes on post title field and dashboard quick post widget.
42390.diff (6.8 KB) - added by afercia 4 months ago.

Download all attachments as: .zip

Change History (34)

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.


20 months ago

#2 @afercia
20 months ago

Worth noting "Enter title here" is not a real placeholder attribute. WordPress uses the field label element and "moves" it to make it visually appear within the field. I'm not saying this is ideal, it just worked this way for years.

#3 @afercia
20 months ago

Discussed a bit during today's accessibility bug-scrub. We think this JS trick was introduced because some years ago not all browsers supported real placeholder attributes. Today, there's the opportunity to use a real label and a real placeholder attribute. This would be more standard and would also allow to remove some JS.

#4 @afercia
20 months ago

  • Focuses administration removed
  • Milestone changed from Awaiting Review to 4.9.1

@Cheffheid
20 months ago

Leaves label hidden with sr-text class, adds placeholder attributes on post title field and dashboard quick post widget.

#5 @Cheffheid
20 months ago

  • Keywords has-patch added

First pass to help get things going. Took out the script that toggles the label into "placeholder mode" and set a proper placeholder on the post title field.

Noticed a similar script was being used on the dashboard for the Quick Draft widget on both the text input and textarea fields in it. Gone ahead and changed that too.

The "default" state for the labels seems to include the screen-reader-text class. I've left that the way it is for now to keep visual impact at a minimum.

https://cldup.com/btOJdJbbdR.gif

https://cldup.com/-0uDSFrVmq.gif

Last edited 20 months ago by Cheffheid (previous) (diff)

#6 @johnbillion
20 months ago

  • Milestone changed from 4.9.1 to 4.9.2

#7 @williampatton
18 months ago

  • Keywords needs-testing added

This ticket was mentioned in Slack in #core by williampatton. View the logs.


18 months ago

#9 @Clorith
18 months ago

  • Keywords needs-testing removed

The patch works fine in Edge for placeholders.

I will have to interject that for a minor update, we shouldn't be removing features or changing long standing behavior. It turns out that quite a few plugins have adopted the *-prompt-text approach from core, and rely on the JavaScript for this.

#10 @afercia
18 months ago

  • Keywords needs-refresh added

I'd agree this seems more something for a major release.

It turns out that quite a few plugins have adopted the *-prompt-text approach from core

Maybe the scripts could be kept and then find a way to not use them in core?

A few notes on the patch:

  • the patch didn't apply cleanly for me, needs a refresh
  • wptitlehint would need to be removed from the variable declarations at the top of the post.js file but if we keep the scripts I guess it should stay
  • the relevant CSS should be removed, but if we keep the scripts I guess it should stay too

More importantly: using the same text for both the visually hidden labels and the placeholder attributes should be avoided, as it would be redundant and not so useful for users. Currently, the same text is announced twice by screen readers:

  • in the post screen: label = Enter title here, placeholder = Enter title here
  • dashboard quick draft: label = What's on your mind?, placeholder = What's on your mind?

Maybe simplifying the label text would be enough:

  • in the post screen: label = Title, placeholder = Enter title here
  • dashboard quick draft: label = Content, placeholder = What's on your mind?

Not sure about the quick draft title, which would be announced as "Title Title". Maybe make it consistent with the post title? " Title Enter title here"?

Last edited 18 months ago by afercia (previous) (diff)

#11 @afercia
18 months ago

Hm, I see there's the enter_title_here filter... not sure what to do with it, but the title and placeholder text should be different.

#12 @afercia
18 months ago

For reference, the filter was added in [16247] see #21584, mainly for custom post types willing to change the visible "placeholder".

#13 @Cybr
18 months ago

Note that this issue affects all input fields that contain placeholders on affected pages.
So, not only the #titlewrap > input field.

#14 @dd32
18 months ago

  • Milestone changed from 4.9.2 to 4.9.3

Bumping to 4.9.3 due to 4.9.2s release

This ticket was mentioned in Slack in #core by desrosj. View the logs.


18 months ago

This ticket was mentioned in Slack in #core by desrosj. View the logs.


18 months ago

#17 @desrosj
18 months ago

  • Milestone changed from 4.9.3 to 4.9.4

Punting to 4.9.4.

#18 @dd32
18 months ago

  • Milestone changed from 4.9.4 to 4.9.5

Bumping, 4.9.4 has been released.

#19 @afercia
17 months ago

  • Milestone changed from 4.9.5 to 5.0

As per @Clorith 's comment I'd propose to move this ticket to 5.0.

#20 @afercia
16 months ago

Investigating a bit on the original issue, I think it's also something related to timing. There are two small pieces of JavaScript involved there: in the Add New post screen, the first JS puts focus on the title field, and the second removes the "placeholder" (actually it's the label).
One of the JS is inline in the page, the other one is in an enqueued script. I think this leads to different behaviors, depending on the browser speed in parsing the page and JS and then run the related JS functions. Hardware can play a role too. This is what I see dumping some debugging text in the console when the two functions run:

IE11 (presumably slower than Edge):

https://cldup.com/YjHTj4j2pJ.png

Edge:

https://cldup.com/sbDSNdnNhs.png

Last edited 16 months ago by afercia (previous) (diff)

This ticket was mentioned in Slack in #accessibility by rianrietveld. View the logs.


10 months ago

#22 @pento
9 months ago

  • Milestone changed from 5.0 to 5.1

#23 @afercia
6 months ago

  • Milestone changed from 5.1 to 5.2

This ticket has a patch (which probably needs a refresh) but the 5.1 release beta 1 is today. Punting to 5.2.

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.


6 months ago

#25 @afercia
6 months ago

  • Owner set to anevins
  • Status changed from new to assigned

This ticket was mentioned in Slack in #accessibility by anevins. View the logs.


5 months ago

@afercia
4 months ago

#27 @afercia
4 months ago

  • Keywords ui-feedback added; needs-refresh removed

turns out that quite a few plugins have adopted the *-prompt-text approach from core, and rely on the JavaScript for this.

  • considering the above
  • considering the new block editor (Gutenberg) doesn't use this technique
  • considering that in my testing there are still different behaviors across browsers and screen readers with regards to the placeholder attribute

I'd propose to not use a placeholder attribute and keep the prompt text in the Classic Editor post title for backwards compatibility. In 42390.diff I've changed and simplified the JavaScript part to make the text behave like a real placeholder:

  • focus on the title field: the text is still visible
  • type something: the text disappears
  • clear the field: the text appears again

Instead, for the Quick Press widget in the Dashboard, I'd propose to make the labels visible. I think this is a good balance between keeping a friendly language ("What’s on your mind?") and the need to properly label these fields.

  • makes the <label>s visible
  • removes all the JavaScript
  • the enter_title_here filter still works on the title label
  • cleans- up the related CSS

Post title:
no visible changes, other than the different behavior of the text visibility

Quick Draft:
see screenshot below:

http://cldup.com/8WBB5sEgXR.png

This ticket was mentioned in Slack in #design by karmatosed. View the logs.


4 months ago

#29 @karmatosed
4 months ago

  • Keywords has-ui-feedback added; ui-feedback removed

Design wise, this was discussed in triage today and is fine to commit.

#30 @afercia
4 months ago

  • Keywords has-screenshots commit added

Forgot to mention the patch is also going to update the Classic Editor "placeholder" (read: label used as fake placeholder) text from "Enter title here" to "Add title", for consistency with Gutenberg:

http://cldup.com/53tx2N9i6l.png

#31 @afercia
4 months ago

  • Resolution set to fixed
  • Status changed from assigned to closed

In 44896:

Accessibility: Improve the placeholder "prompt" text in the post title and Quick Draft widget.

Old browsers didn't support the HTML placeholder attribute. For a number of years, <label> elements have been used in a few places in WordPress to emulate placeholders. It's time to improve semantics and interaction, use real placeholders when possible, and clean up some JavaScript.

  • Quick Draft widget: it now uses visible <label> elements and a real placeholder attribute
  • removes the related JavaScript
  • Post title:
    • keeps the "prompt" label for backwards compatibility
    • improves the JavaScript to make the "prompt" label stay visible on focus and disappear when typing, like real placeholder do
  • changes the post "prompt" text from "Enter title here" to "Add title" for consistency with the Block Editor
  • cleans-up some CSS

Props Cheffheid, afercia.
Fixes #42390.

This ticket was mentioned in Slack in #accessibility by anevins. View the logs.


3 months ago

Note: See TracTickets for help on using tickets.