The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: jorgefilipecosta <jorgefilipecosta@git.wordpress.org>
Co-authored-by: t-hamano <wildworks@git.wordpress.org>
Co-authored-by: mcsf <mcsf@git.wordpress.org>
Co-authored-by: mtias <matveb@git.wordpress.org>
Co-authored-by: jasmussen <joen@git.wordpress.org>
Co-authored-by: mrwweb <mrwweb@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

Size Change: -471 B (-0.02%)

Total Size: 2.58 MB

_{compressed-size-action}

Backporting this to a minor release seems like it would have too much of an impact.

For example, this PR adds new strings. In general, adding new translation strings is not allowed after the RC release.

Backporting this to a minor release seems like it would have too much of an impact.

For example, this PR adds new strings. In general, adding new translation strings is not allowed after the RC release.

Good points, but it is not the first time a minor release is complex, for example some releases between 4.9 and 5.0 were considerably big. Off-course adding this in a minor would require leadership backing, as it is not something usual.

Let's ship this in the plugin and give it a little time of testing before deciding if we should make it part of a minor release.

This PR got some conflicts and was rebased. I think it is ready for a review.

I'm here for it!

I'm very happy to see this change back to the old UI! I think it makes a lot of sense for all the stated reasons.

Two notes on things I've learned and thought about since the launch:

1. I am wondering if it's possible to make the stretchy text effect in addition to font size, rather than instead of. Supporting a specified font size on page load provides a better fallback and, more importantly, can meaningfully reduce the change in font size when the script kicks in (i.e., "Flash of un-fitted text")
2. I believe that most fit text implementations fail WCAG 1.4.4: "Except for captions and images of text, text can be resized without assistive technology up to 200 percent without loss of content or functionality." I don't know how easy it is to avoid this failure, but it would be great to support it. If not, it may be worth adding a warning about using the feature (Gravity Forms has a good version of this field when you hide a form label.)

I am wondering if it's possible to make the stretchy text effect in addition to font size, rather than instead of. Supporting a specified font size on page load provides a better fallback and, more importantly, can meaningfully reduce the change in font size when the script kicks in (i.e., "Flash of un-fitted text")

It is a good point, but allowing font size with it being a fallback may not be intuitive for the users, as it looks like nothing happened.

I believe that most fit text implementations fail WCAG 1.4.4: "Except for captions and images of text, text can be resized without assistive technology up to 200 percent without loss of content or functionality." I don't know how easy it is to avoid this failure, but it would be great to support it. If not, it may be worth adding a warning about using the feature (Gravity Forms has a good version of this field when you hide a form label.)

It is a complex scenario, putting 200% zoom does not breaks fit text, as it recomputes the maximum possible size, and fits independently of the zoom settings. But depending on the container layout zooming in to 200% may not make fit text 200% bigger, unless the container also increase 200% its size which is rarely the case. So we are in situation where we don't break functionality when there is a 200% in that sense we are complying. The issue may be that with 200% zoom fit text does not gets 200% bigger because it may have already used the maximum size for its container. I'm not sure if this is complying or not. But if we are not complying I guess we should mark fit text as an "image text"/decoration, if it was an SVG implementation it would be an image.

Thank you all for the reviews!

@jorgefilipecosta

It is a good point, but allowing font size with it being a fallback may not be intuitive for the users, as it looks like nothing happened.

Absolutely no shift of font size would be the ideal outcome as that wouldn't be any different than the page loading with the exact correct font size. However, that also strikes me as extremely unlikely, and at least reducing the content shift would be greatly appreciated.

The issue may be that with 200% zoom fit text does not gets 200% bigger because it may have already used the maximum size for its container.

That's correct. Zooming 200% is supposed to make the text 200% better.

But if we are not complying I guess we should mark fit text as an "image text"/decoration, if it was an SVG implementation it would be an image.

Please do not do this! People definitely expect written content to be included in the document. Marking it as decorative could potentially remove the content from the accessibility tree, breaking accessibility in a new way.

Is it possible for the Accessibility Team to weigh in on this?