Add width utility to limit line length for readability

[dylanatsmith]

What are you trying to accomplish?

Add a utility class to limit line length to a more comfortable number of characters.

This screen recording shows the effect of toggling between max-width: 100% and max-width: 75ch on an example GitHub settings page.

Screen.Recording.2023-01-13.at.15.41.19.mov

What approach did you choose and why?

New width- utility class.

What should reviewers focus on?

Does 65 feel right? @ericwbailey notes in a comment below that line lengths of 80 characters or fewer would be WCAG compliant. In my experience, 70–75 feels a little better for paragraphs, but shorter can be nicer in product UI due to the shorter overall strings.

Can these changes ship as is?

• Yes, this PR does not depend on additional changes. 🚢

Note: I’m not familiar enough with Primer processes to know what else we’d need to do to ship this, but it’s a standalone class addition.

[changeset-bot]

🦋 Changeset detected

Latest commit: e7babb4

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@primer/css	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[ericwbailey]

I think this would be a very welcome addition.

Part of WCAG Success Criterion 1.4.8 Visual Presentation is guaranteeing:

Width is no more than 80 characters or glyphs (40 if CJK).

SC 1.4.8 is also level AAA, so it technically does not apply to GitHub's minimum WCAG level of support, which is AA. That said, a comfortable maximum line width for English content and helps a lot with reading, comprehension, retention, Dyslexia, ESL, and other concerns.

I also appreciate the comment specifically calls out text content as what it should be used for.

[simurai]

Would this utility be added to a parent container (e.g. replace container-md with width-comfortable)? Or manually added on each <p>. For the later it might create this stair effect where things have different widths:

Text vs heading	Text with different font-size

I guess it's a good thing for readability, but does that look visually weird?

Also if one settings page would start using this utility class, we probably should add it to all settings pages and use the same behavior? Maybe more a .width-comfortable p selector? Or make it an option on the Layout component.

[dylanatsmith]

Would this utility be added to a parent container (e.g. replace container-md with width-comfortable)? Or manually added on each <p>. For the later it might create this stair effect where things have different widths:
Text vs heading Text with different font-size

I guess it's a good thing for readability, but does that look visually weird?

Also if one settings page would start using this utility class, we probably should add it to all settings pages and use the same behavior? Maybe more a .width-comfortable p selector? Or make it an option on the Layout component.

Sorry @simurai, suuuuper late coming back to this.

My thinking was that it could be used on "problem" elements, like individual p or label tags, to fix individual cases.

It could also be used on parent containers but the risk would be that there are elements we want to keep full-width and it causes problem. Imagine where we have a div with a banner and then a paragraph, for example.

I could run a few tests if that'd help illustrate intended usage better.

[simurai]

It could also be used on parent containers but the risk would be that there are elements we want to keep full-width and it causes problem.

On a parent container, I feel like it should only be used with caution, since child elements could have different font-sizes.

My thinking was that it could be used on "problem" elements, like individual p or label tags, to fix individual cases.

But, yeah.. when used intentionally for certain text elements, that should be fine. 👍

[dylanatsmith]

Given we have approval here, are we able to merge? I’m not familiar with the process (and don’t think I have write permissions). @simurai

[simurai]

and don’t think I have write permissions

Ahh.. right. And I lost my write permission. 😅

Maybe @langermank still has that power?