Introduce a typographic measure for the admin screens

[afercia]

For optimal readability, lines of text shouldn't exceed a certain length. In typography, this is called ​measure and looking around for references you will find several (different) recommendations, starting from 45-50 characters per line till 90 or even more.

By the way, there's no such a thing as an absolute, perfect, number to fit all the different cases. It depends on many different factors, starting from the typeface used, its metrics, if it's a single column or multi-column layout etc.

That said, when a line of text is really, really, too long, then readability, usability, and accessibility, they're all seriously affected.

I'd like to encourage typography lovers and designers to start some discussion, research, and development with the long-term goal to improve typography in the admin screens. Trying to implement a measure could be a nice start.

Also, I'd like to propose to consider the introduction of a new "typography" focus tag for Trac.

In the screenshots below: a couple examples of some admin screens rendered on a large display with the browser's window maximized.

[michaelarestad]

You mean like in Tools?

Note: this is NOT an ideal solution, but I'm working on it. :)

[afercia]

Replying to michaelarestad:

You mean like in Tools?

Yep, Tools visually renders the idea. Was thinking more to a reusable CSS class to be used where necessary in the admin, setting a max-width to the actual content (not the container) and probably expressed in em. Probably needs some research.

[michaelarestad]

Yep, Tools visually renders the idea. Was thinking more to a reusable CSS class to be used where necessary in the admin, setting a max-width to the actual content (not the container) and probably expressed in em. Probably needs some research.

Yep. Definitely was planning on doing something similar that, which makes the container a bit more flexible.

[afercia]

Quickly discussed in today's accessibility meeting and one option could be introducing a max-width for some elements to begin with. Thinking for example at paragraphs in the settings screens. And then progressively extend the new rule to other screens, where necessary. Moving to 4.8 for discussion and experimentation.

[afercia]

Punting as we're running out of time for the 4.8 release.

[rishishah]

It looks like it's a CSS issue, So I have added the css code to the '.contextual-help-tabs-wrap' class so now the text is showing in the limit.

@afercia Please check my patch and let me know if there is any changes needs to be done by me.

[afercia]

@rishishah thanks! The best option would be creating a new, re-usable CSS class so that it can be used also in other places.

Worth nothing patches should be created from a version-controlled copy of WordPress trunk installed from the develop repository ​https://develop.svn.wordpress.org/trunk/ (trunk doesn't have .rtl files, they're generated during the build process).

You can read more about the whole process on the WordPress handbook:
​https://make.wordpress.org/core/handbook/contribute/
​https://make.wordpress.org/core/handbook/tutorials/installing-wordpress-locally/
You can either choose to manually install a local server or use VVV (Varying Vagrant Vagrants)
​https://make.wordpress.org/core/handbook/tutorials/installing-a-local-server/installing-vvv/

Also:
​https://make.wordpress.org/core/handbook/tutorials/working-with-patches/#creating-a-patch
Patches should be created from the root directory of your WordPress SVN install so that paths within the file start with src/.

[rishishah]

Thanks @afercia for the instruction. I have added c new class "typographic-text-wrap" for the re-usable CSS on this particular class. I have a added a second patch please review it and let me know if anything. Thanks,

[afercia]

Punting to 4.9 as per today's bug scrub.

[afercia]

It would be great to have some feedback from the design team :)

[melchoyce]

I'm having trouble applying the patch since it was done on trunk, not src — can someone with more svn knowledge add a patch from the right location?

[afercia]

@melchoyce it's 3 lines of code :) can also be changed manually, Will try to refresh the patch as soon as I have time.

[xkon]

Updated for svn use.

[xkon]

@melchoyce I guess 34991.3.diff​ will be ok for you.

[rishishah]

Hello @afercia and @melchoyce I have update my old patch with src.

[afercia]

Thanks @rishishah !

General considerations:
in typography, a line length is called ​measure so I'd consider to rename the classe from .typographic-text-wrap to .typographic-measure or simply .measure

Not sure it should be expressed in pixels or em, and not sure about the value. It should result in approximately 80-100 characters. I'd try something like 44em since it should be based on the font size.

It is meant for general use, not just for the help tabs, so I'd place it in common.css in a general section (even if the file sections have lost a clear distinction over time).

[afercia]

Patch did not apply cleanly because of very recent changes. Refreshed and updated accordingly to previous comment.

[afercia]

For a comparison, see the screenshots in the ticket description above and the ones below:

Help tabs:

Discussion settings (not applied on the current patch):

Worth reminding the proposed new CSS class is meant to be a general utility class and can be applied on any text block, when necessary. I'd propose to introduce it in core and keep it simple to start experimenting with it.

In the future, maybe consider to extend it and introduce a set of "measure" classes with different values, for example:

.measure-40 { max-width: 40em; }
.measure-44 { max-width: 44em; }
.measure-48 { max-width: 48em; }
...

[afercia]

Closing as per today's discussion on Slack #design (see link above).

Opinions differ and there's no consensus. It was pointed out that the max-width issue should be addressed with new designs in the "views" themselves, not with a generic class.

[afercia]

For reference, adding to this old ticket one new example where long lines of text makes readability a bit challenging: the Privacy Settings page.

I'd like to propose to reopen this ticket for new consideration.

[afercia]

Worth noting the Privacy Policy Guide page in WordPress 5.2 does set a max-width in the content (see screenshot below), though it appears to be a very unique case in the admin pages.

It would be great to establish a solid pattern to be applied to all the blocks of text with very long lines in the admin.

[melchoyce]

@drw158 has a typography proposal that would be a good pre-cursor to exploring this issue: ​https://make.wordpress.org/design/2019/10/11/proposal-a-consistent-type-scale-for-wordpress/

Let's try to get that implemented, and then revisit line-length.

[afercia]

Thinking now that there's a CSS component, this issue might be of interest of the CSS team.

[carike]

If I understand correctly the only change this makes to the privacy policy is to reduce the number of characters per line? :D (Would love that, by the way!)
Thanks for the ping, @paaljoachim. I don't see any issues from a privacy side, but it is always nice to be asked beforehand, rather than having to fix bigger issues later! :)