Placeholder for tagline is confusing

[Cybr]

Previous: #6479 (Encourage people to change default tagline).

The default tagline got emptied. To maintain the iconic phrase "Just another WordPress site," it was put as a placeholder for the field.

Placeholders are generally bad for accessibility because many users cannot discern whether it's actual input or the real value. See ​https://www.nngroup.com/articles/form-design-placeholders/.

The highlights:

4. Placeholder text that disappears when the cursor is placed in a form field is irritating for users navigating with the keyboard.
5. Fields with stuff in them are less noticeable.
6. Users may mistake a placeholder for data that was automatically filled in.
7. Occasionally users have to delete placeholder text manually.

By putting e.g., in front of the placeholder, this may be somewhat alleviated. Perhaps it might be best to let go of the iconic phrase altogether until a proper admin interface is found where we may reintroduce it.

[audrasjb]

Hello and thanks for the ticket!

In my opinion, putting e.g., in front of the placeholder looks like the best option for now.

[sabernhardt]

Thanks for the ticket!

The tagline's placeholder does not replace a label, and its information is nonessential to complete the form. I do not think disappearing text is a problem for this field, but confusion about whether the example is the input's predefined value still could be a concern. The example tagline may fit better within the description paragraph.

[Cybr]

I think @sabernhardt's patch deals perfectly with all the concerns described.

Though the added text relies on vertical and code-indented spacing to add a space between the two lines, doing that bit me at least once during refactorization.

Opening and closing PHP tags isn't great for performance, either. But this is nitpicking.

[sabernhardt]

Nitpicking is good. I missed the __() translation function, too.

Also, I would like to consider keeping the example on one line with a reusable class for display: inline-block (I have wanted the class for something else before).

[sabernhardt]

adding example to field description, without inline-block styling

[sabernhardt]

I removed the new inline-block class from the patch. Searching for an ​'inline-block' class included a plugin that adds vertical-align: middle, and others may have inappropriate properties for this description. Besides, it was not clearly better with that span.

[audrasjb]

57675.2.patch looks good, except we'd probably need a final dot in this paragraph?

[audrasjb]

57675.2.patch looks good to me. Should we have a final dot in English, though?

[audrasjb]

Patch tested on multisite as well

[sabernhardt]

The period should be unnecessary with the "Example: [tagline]" structure, though it could easily be appropriate in translations. In U.S. English, the period would go inside the quotes, which I do not like here.

[audrasjb]

Ok then we have to add a period inside the quote of the existing string, right?

[Cybr]

The clearest notion about whether the period should be in or outside is this (​source):

The final period or comma goes inside the quotation marks, even if it is not a part of the quoted material, unless the quotation is followed by a citation.

Since we aren't dealing with a citation, and since the default WordPress language is en_US, the period should be inside the quote marks.

I'm not a fan of this either when dealing with example strings that don't have punctuation intended — for the user could infer they should also use punctuation —, but I think we should follow the books. I couldn't find a single source claiming exceptions for American English.

We could somewhat workaround the inference by writing "Just another WordPress site," for example., but even then we have punctuation.

[pavanpatil1]

Test report - https://core.trac.wordpress.org/attachment/ticket/57675/57675.2.patch

Environment:
WordPress: v6.2.2
Browser: Chrome
Os - Win10

Screenshot- ​https://prnt.sc/3zfv7AacldMD

The patch is looking good!