WordPress.org

Make WordPress Core

Opened 21 months ago

Last modified 3 weeks ago

#34991 assigned feature request

Introduce a typographic measure for the admin screens

Reported by: afercia Owned by: afercia
Milestone: 4.9 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 (2)

34991.patch (377 bytes) - added by rishishah 3 months ago.
34991.2.patch (905 bytes) - added by rishishah 3 months ago.

Download all attachments as: .zip

Change History (21)

#1 follow-up: @michaelarestad
21 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
21 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
21 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.


20 months ago

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


12 months ago

#6 @rianrietveld
12 months ago

  • Milestone changed from Awaiting Review to Future Release

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


6 months ago

#8 @afercia
6 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 3 months ago by afercia (previous) (diff)

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


3 months ago

#10 @afercia
3 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
3 months ago

  • Milestone changed from Future Release to 4.8.1

#12 @rishishah
3 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
3 months ago

#13 @afercia
3 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
3 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
3 months ago

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


8 weeks ago

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


5 weeks ago

#17 @afercia
5 weeks ago

  • Milestone changed from 4.8.1 to 4.9

Punting to 4.9 as per today's bug scrub.

#18 @afercia
5 weeks 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 weeks ago

Note: See TracTickets for help on using tickets.