Make WordPress Core

Opened 3 years ago

Closed 9 months ago

#32062 closed defect (bug) (invalid)

Press This, Doesn't Show Any Tags

Reported by: miqrogroove Owned by:
Milestone: Priority: normal
Severity: normal Version: 4.2
Component: Press This Keywords: has-patch
Focuses: ui, accessibility Cc:


I tried the Press This direct link for the first time today using iOS 8.2 Safari, on WP 4.2-RC3.

The Categories menu works, but the tags menu does not. A "choose from the most used tags" link appears, and when I tap it the response is "no tags found". This might be because it is a test site and none of the tags have been used yet. However, I would expect the unused tags to appear instead of a blank menu and a link that doesn't do anything.

Attachments (5)

image.jpg (113.8 KB) - added by miqrogroove 3 years ago.
Screen Shot
image.2.jpg (63.3 KB) - added by stephdau 3 years ago.
"no tags found" message, iOS 8.2 on iPad Mini.
image.3.jpg (131.6 KB) - added by miqrogroove 3 years ago.
In 4.1, it was obvious that typing was required for tags.
32062.diff (939 bytes) - added by DrewAPicture 3 years ago.
32062.2.diff (1.1 KB) - added by DrewAPicture 3 years ago.

Download all attachments as: .zip

Change History (20)

3 years ago

Screen Shot

#1 @stephdau
3 years ago

Press This shows a "no tags found" message when there are no tags in your install, or if none are used yet, indeed. The link does say "most used". Autocomplete on the text field will display the existing tags, regardless of if they're used or not.

Note that this behavior is not Press This specific, as the equivalent feature in the standard post editor works the same way (Press This replicates that).

Last edited 3 years ago by stephdau (previous) (diff)

3 years ago

"no tags found" message, iOS 8.2 on iPad Mini.

#2 @miqrogroove
3 years ago

This appears to be a regression from 4.1. I'll put a screen shot from 4.1 to compare the UI changes. The new version shows a blank menu, whereas the old version shows checkboxes for Categories and textbox for Tags.

3 years ago

In 4.1, it was obvious that typing was required for tags.

#3 @miqrogroove
3 years ago

I'll leave this open to interpretation, but I find the new tags interface much more confusing.

#4 @kraftbj
3 years ago

The Press This behavior appears to be the same as the wp-admin post-new.php from my quick look. I would suggest deferring to however Core handles this more broadly [w/r/t the "No Tags Found" link].

Last edited 3 years ago by kraftbj (previous) (diff)

#5 @stephdau
3 years ago

I see what you mean in regards to the UI. Wanna chime in, @michaelarestad?

#6 @miqrogroove
3 years ago

One other inconsistency: The Categories textbox has default text "Search categories by name" whereas the Tags textbox is blank by default.

#7 @Michael Arestad
3 years ago

No tags found: As was mentioned, it simply mirrors the behavior of the tags box in the standard editor. I, however am not at all happy with the tag cloud UI. I would rather we show a list of every tag, used or not, in order of most common to least (similarish to categories).

Placeholder text: When we were in plugin phase, it wasn't trivial to change the placeholder. Now, it might be too late with the string freeze, but I'd like to add one. Placeholder text would drastically improve the UI.

Last edited 3 years ago by Michael Arestad (previous) (diff)

#8 @helen
3 years ago

  • Milestone changed from Awaiting Review to 4.2

There's "Add New Tag" in the taxonomy labels if that's good enough - it isn't really, but as far as existing strings go I think that's what we've got. It is pretty weird to have it totally blank.

#9 @helen
3 years ago

Also, comparing to previous UI, it is "the same", but the input isn't very input-y, so we lose that affordance.

#10 @afercia
3 years ago

Please consider placeholder text is not a substitute for labels. Though they're often (mistakenly) used to provide a "visual" feedback, their purpose should be to give an hint about the type of data to enter. http://www.w3.org/TR/html5/forms.html#the-placeholder-attribute

From an accessibility point of view, placeholder text should never repeat the same information already provided with the label. References:

The Paciello Group HTML5 Accessibility Chops: the placeholder attribute http://www.paciellogroup.com/blog/2011/02/html5-accessibility-chops-the-placeholder-attribute/

Nielsen Norman Group Placeholders in Form Fields Are Harmful http://www.nngroup.com/articles/form-design-placeholders/

Roger Johansson - 456 Berea Street The HTML5 placeholder attribute is not a substitute for the label element http://www.456bereastreet.com/archive/201204/the_html5_placeholder_attribute_is_not_a_substitute_for_the_label_element/

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

3 years ago

3 years ago

3 years ago

#12 @DrewAPicture
3 years ago

  • Focuses ui added
  • Keywords has-patch added

With 32062.diff:

  • Uses the add_new_item taxonomy label


With 32062.2.diff:

  • Uses the separate_items_with_commas taxonomy label, hides the aria-describedby element with screen-reader-text


#13 @helen
3 years ago

  • Milestone changed from 4.2 to Future Release

I do like the placeholder move in theory, but in execution it is not pretty. I still agree that the bare experience is lacking, but given constraints of things like string freeze and how browsers treat placeholders, we can't do this any better in 4.2. Punting.

#14 @swissspidy
18 months ago

  • Focuses accessibility added

#15 @kraftbj
9 months ago

  • Milestone Future Release deleted
  • Resolution set to invalid
  • Status changed from new to closed

With Press This spinning out to be a separate plugin, moving this convo to https://github.com/WordPress/press-this/issues/10

Note: See TracTickets for help on using tickets.