WordPress.org

Make WordPress Core

Opened 23 months ago

Closed 4 weeks ago

#34991 closed feature request (wontfix)

Introduce a typographic measure for the admin screens

Reported by: afercia Owned by: afercia
Milestone: Priority: normal
Severity: normal Version:
Component: Administration Keywords: has-patch has-screenshots
Focuses: ui, accessibility Cc:

Description

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.

https://cldup.com/Lqn6W2CVsy.png

https://cldup.com/CV2JcdQI1w.png

Attachments (5)

34991.patch (377 bytes) - added by rishishah 5 months ago.
34991.2.patch (905 bytes) - added by rishishah 5 months ago.
34991.3.diff (890 bytes) - added by xkon 4 weeks ago.
Updated for svn use.
34991.3.patch (890 bytes) - added by rishishah 4 weeks ago.
Hello @afercia and @melchoyce I have update my old patch with src.
34991.diff (895 bytes) - added by afercia 4 weeks ago.

Download all attachments as: .zip

Change History (35)

#1 follow-up: @michaelarestad
23 months ago

You mean like in Tools?

https://cldup.com/jQy9xf2q17.png

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

#2 in reply to: ↑ 1 @afercia
23 months ago

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.

#3 @michaelarestad
23 months ago

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.

This ticket was mentioned in Slack in #glotpress by ocean90. View the logs.


23 months ago

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


15 months ago

#6 @rianrietveld
15 months ago

  • Milestone changed from Awaiting Review to Future Release

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


9 months ago

#8 @afercia
9 months ago

  • Milestone changed from Future Release to 4.8
  • Owner set to afercia
  • Status changed from new to assigned

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.

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

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


6 months ago

#10 @afercia
6 months ago

  • Milestone changed from 4.8 to Future Release

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

#11 @afercia
6 months ago

  • Milestone changed from Future Release to 4.8.1

#12 @rishishah
5 months ago

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.

http://i.imgur.com/0104vSB.jpg

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

@rishishah
5 months ago

#13 @afercia
5 months ago

  • Version 4.4 deleted

@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/.

#14 @rishishah
5 months ago

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,

@rishishah
5 months ago

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


4 months ago

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


3 months ago

#17 @afercia
3 months ago

  • Milestone changed from 4.8.1 to 4.9

Punting to 4.9 as per today's bug scrub.

#18 @afercia
3 months ago

  • Keywords has-patch has-screenshots added

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

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


3 months ago

#20 @melchoyce
4 weeks ago

  • Keywords ui-feedback added

#21 @melchoyce
4 weeks ago

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?

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


4 weeks ago

#23 @afercia
4 weeks ago

@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
4 weeks ago

Updated for svn use.

#24 @xkon
4 weeks ago

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

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


4 weeks ago

@rishishah
4 weeks ago

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

#26 @afercia
4 weeks ago

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
4 weeks ago

#27 @afercia
4 weeks ago

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

#28 @afercia
4 weeks ago

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

Help tabs:

https://cldup.com/B4wFO8Nzqb.jpg

Discussion settings (not applied on the current patch):

https://cldup.com/PKGvTRNZGh.jpg

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; }
...

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


4 weeks ago

#30 @afercia
4 weeks ago

  • Keywords ui-feedback removed
  • Milestone 4.9 deleted
  • Resolution set to wontfix
  • Status changed from assigned to closed

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.

Note: See TracTickets for help on using tickets.