Text Autosizing for mobile browsers (master bug)

• Component: Text
• Status: RESOLVED WONTFIX

[John Mellor]

Master bug to track progress and related issues.

When viewing desktop websites on mobile devices, browsers usually layout the page at a fixed width of about 980 CSS pixels due to the default viewport settings. The user usually can't read the text when the page is initially displayed, but can zoom in to read it. However on a portrait phone screen, once zoomed in such that text is a legible size, only about a 320 CSS pixel wide area of content fits onscreen at a time.

For wide columns of text, this means you'd either need to zoom out and look at tiny unreadable / barely readable text, or you'd need to pan left and right for every line of text you read. The same thing happens (though less severely) on landscape phones and on portrait tablets.

To prevent such situations, this bug tracks adding support for Font Boosting (upstreamed from Chrome for Android). When pages load, Font Boosting increases the font size of text in wide columns, so you won't have to zoom in on them as much and hence every column fits onscreen at a legible text size.

Related Links
-------------
Firefox Mobile:
- Description: http://dbaron.org/log/20111126-font-inflation
- Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=627842
- Dev doc: https://developer.mozilla.org/en/CSS/text-size-adjust
Mobile Safari:
- Dev doc: http://goo.gl/rRIiF
Internet Explorer:
- Dev doc: http://msdn.microsoft.com/en-us/library/ff462082(v=vs.92).aspx#sectionToggle2
- Interaction with Compatibility View: http://goo.gl/QdhRm

[Simon Hausmann]

For reference, bug #73546 is about upstreaming the iOS feature.

[Adam Barth]

What's the next step here?

[John Mellor]

Created attachment 143381 [details]
Patch

[Adam Barth]

Comment on attachment 143381 [details]
Patch

Clearing the review flag because the ChangeLog says this patch isn't meant for review.

[WebKit Review Bot]

Please wait for approval from [e-mail], [e-mail], [e-mail], [e-mail] or [e-mail] before submitting, as this patch contains changes to the Chromium public API. See also https://trac.webkit.org/wiki/ChromiumWebKitAPI.

[WebKit Review Bot]

Attachment 143381 [details] did not pass style-queue:

Source/WebCore/rendering/style/RenderStyle.cpp:336:  Should have only a single space after a punctuation in a comment.  [whitespace/comments] [5]
Source/WebCore/rendering/style/RenderStyle.cpp:368:  Boolean expressions that span multiple lines should have their operators on the left side of the line instead of the right side.  [whitespace/operators] [4]
Source/WebCore/rendering/style/RenderStyle.cpp:369:  Boolean expressions that span multiple lines should have their operators on the left side of the line instead of the right side.  [whitespace/operators] [4]
Source/WebCore/rendering/style/RenderStyle.cpp:370:  Boolean expressions that span multiple lines should have their operators on the left side of the line instead of the right side.  [whitespace/operators] [4]
Source/WebCore/rendering/style/RenderStyle.cpp:371:  Boolean expressions that span multiple lines should have their operators on the left side of the line instead of the right side.  [whitespace/operators] [4]
Source/WebCore/rendering/style/RenderStyle.cpp:372:  Boolean expressions that span multiple lines should have their operators on the left side of the line instead of the right side.  [whitespace/operators] [4]
Source/WebCore/rendering/style/RenderStyle.cpp:373:  Boolean expressions that span multiple lines should have their operators on the left side of the line instead of the right side.  [whitespace/operators] [4]
Source/WebCore/rendering/style/RenderStyle.cpp:374:  Boolean expressions that span multiple lines should have their operators on the left side of the line instead of the right side.  [whitespace/operators] [4]
Source/WebCore/rendering/style/RenderStyle.cpp:375:  Boolean expressions that span multiple lines should have their operators on the left side of the line instead of the right side.  [whitespace/operators] [4]
Source/WebCore/rendering/style/RenderStyle.cpp:376:  Boolean expressions that span multiple lines should have their operators on the left side of the line instead of the right side.  [whitespace/operators] [4]
Source/WebCore/rendering/style/RenderStyle.cpp:377:  Boolean expressions that span multiple lines should have their operators on the left side of the line instead of the right side.  [whitespace/operators] [4]
Source/WebCore/rendering/style/RenderStyle.cpp:378:  Boolean expressions that span multiple lines should have their operators on the left side of the line instead of the right side.  [whitespace/operators] [4]
Source/WebCore/rendering/style/RenderStyle.cpp:379:  Boolean expressions that span multiple lines should have their operators on the left side of the line instead of the right side.  [whitespace/operators] [4]
Source/WebCore/rendering/style/RenderStyle.cpp:380:  Boolean expressions that span multiple lines should have their operators on the left side of the line instead of the right side.  [whitespace/operators] [4]
Source/WebCore/rendering/style/RenderStyle.cpp:381:  Boolean expressions that span multiple lines should have their operators on the left side of the line instead of the right side.  [whitespace/operators] [4]
Source/WebCore/rendering/style/RenderStyle.cpp:382:  Boolean expressions that span multiple lines should have their operators on the left side of the line instead of the right side.  [whitespace/operators] [4]
Source/WebCore/rendering/style/RenderStyle.cpp:383:  Boolean expressions that span multiple lines should have their operators on the left side of the line instead of the right side.  [whitespace/operators] [4]
Source/WebCore/rendering/style/RenderStyle.cpp:384:  Boolean expressions that span multiple lines should have their operators on the left side of the line instead of the right side.  [whitespace/operators] [4]
Source/WebCore/rendering/style/RenderStyle.cpp:385:  Boolean expressions that span multiple lines should have their operators on the left side of the line instead of the right side.  [whitespace/operators] [4]
Source/WebCore/dom/Document.h:275:  Missing space before {  [whitespace/braces] [5]
Source/WebCore/dom/Document.h:282:  The parameter name "node" adds no information, so it should be removed.  [readability/parameter_name] [5]
Source/WebCore/dom/Document.h:283:  Extra space before ( in function call  [whitespace/parens] [4]
Source/WebCore/dom/Document.h:284:  Extra space before ( in function call  [whitespace/parens] [4]
Source/WebCore/rendering/FontBoostingCluster.cpp:41:  Use 'using namespace std;' instead of 'using std::max;'.  [build/using_std] [4]
Source/WebCore/rendering/FontBoostingCluster.cpp:42:  Use 'using namespace std;' instead of 'using std::min;'.  [build/using_std] [4]
Source/WebCore/rendering/FontBoostingCluster.cpp:100:  Should have a space between // and comment  [whitespace/comments] [4]
Source/WebCore/rendering/FontBoostingCluster.cpp:133:  One line control clauses should not use braces.  [whitespace/braces] [4]
Source/WebCore/rendering/FontBoostingCluster.cpp:220:  MAX_X_DISTANCE is incorrectly named. Don't use underscores in your identifier names.  [readability/naming] [4]
Source/WebCore/rendering/FontBoostingCluster.cpp:221:  MAX_Y_DISTANCE is incorrectly named. Don't use underscores in your identifier names.  [readability/naming] [4]
Source/WebCore/rendering/FontBoostingCluster.cpp:286:  RATE_OF_INCREASE_OF_BOOSTED_SIZE_AFTER_MIN_SIZE is incorrectly named. Don't use underscores in your identifier names.  [readability/naming] [4]
Source/WebKit/chromium/src/WebSettingsImpl.cpp:495:  Tests for true/false, null/non-null, and zero/non-zero should all be done without equality comparisons.  [readability/comparison_to_zero] [5]
Source/WebCore/rendering/RenderObject.h:220:  The parameter name "inclusionFunction" adds no information, so it should be removed.  [readability/parameter_name] [5]
Source/WebCore/rendering/RenderObject.h:221:  The parameter name "inclusionFunction" adds no information, so it should be removed.  [readability/parameter_name] [5]
Source/WebCore/rendering/RenderObject.h:224:  The parameter name "render" adds no information, so it should be removed.  [readability/parameter_name] [5]
Source/WebCore/dom/Document.cpp:5242:  Should have a space between // and comment  [whitespace/comments] [4]
Source/WebCore/dom/Document.cpp:5309:  Place brace on its own line for function definitions.  [whitespace/braces] [4]
Source/WebCore/dom/Document.cpp:5310:  Should have a space between // and comment  [whitespace/comments] [4]
Source/WebCore/dom/Document.cpp:5419:  One line control clauses should not use braces.  [whitespace/braces] [4]
Source/WebCore/rendering/RenderBlock.cpp:74:  FB_SET_ATTR is incorrectly named. Don't use underscores in your identifier names.  [readability/naming] [4]
Source/WebCore/rendering/RenderBlock.cpp:7345:  Declaration has space between type name and * in RenderText *renderText  [whitespace/declaration] [3]
Source/WebCore/rendering/RenderBlock.cpp:7347:  Tests for true/false, null/non-null, and zero/non-zero should all be done without equality comparisons.  [readability/comparison_to_zero] [5]
Source/WebCore/rendering/RenderBlock.cpp:7350:  Place brace on its own line for function definitions.  [whitespace/braces] [4]
Source/WebCore/rendering/RenderBlock.cpp:7395:  Tests for true/false, null/non-null, and zero/non-zero should all be done without equality comparisons.  [readability/comparison_to_zero] [5]
Source/WebCore/rendering/RenderBlock.cpp:7403:  One line control clauses should not use braces.  [whitespace/braces] [4]
Source/WebCore/rendering/RenderBlock.cpp:7468:  Declaration has space between type name and * in RenderText *text  [whitespace/declaration] [3]
Source/WebCore/rendering/RenderBlock.cpp:7469:  Declaration has space between type name and * in RenderStyle *oldStyle  [whitespace/declaration] [3]
Source/WebCore/rendering/RenderBlock.cpp:7516:  One line control clauses should not use braces.  [whitespace/braces] [4]
Source/WebCore/rendering/RenderBlock.cpp:7518:  One line control clauses should not use braces.  [whitespace/braces] [4]
Source/WebCore/rendering/style/StyleInheritedData.h:58:  specified_line_height is incorrectly named. Don't use underscores in your identifier names.  [readability/naming] [4]
Source/WebCore/renderFailed to run "['Tools/Scripts/check-webkit-style', '--diff-files', u'LayoutTests/ChangeLog', u'LayoutTests/plat..." exit_code: 1
ing/RenderBlockLineLayout.cpp:1548:  TEXT_REFLOW_MARGIN_PADDING is incorrectly named. Don't use underscores in your identifier names.  [readability/naming] [4]
Source/WebCore/rendering/RenderObject.cpp:85:  "Settings.h" already included at Source/WebCore/rendering/RenderObject.cpp:66  [build/include] [4]
Source/WebCore/platform/graphics/FontDescription.h:171:  Place brace on its own line for function definitions.  [whitespace/braces] [4]
Source/WebCore/platform/graphics/FontDescription.h:171:  Extra space before ( in function call  [whitespace/parens] [4]
Source/WebCore/platform/graphics/Font.h:233:  Place brace on its own line for function definitions.  [whitespace/braces] [4]
Source/WebCore/platform/graphics/Font.h:233:  Extra space before ( in function call  [whitespace/parens] [4]
Source/WebCore/platform/graphics/Font.h:234:  Boolean expressions that span multiple lines should have their operators on the left side of the line instead of the right side.  [whitespace/operators] [4]
Source/WebCore/platform/graphics/Font.h:235:  Boolean expressions that span multiple lines should have their operators on the left side of the line instead of the right side.  [whitespace/operators] [4]
Tools/DumpRenderTree/chromium/WebViewHost.cpp:742:  An else statement can be removed when the prior "if" concludes with a return, break, continue or goto statement.  [readability/control_flow] [4]
Total errors found: 58 in 45 files


If any of these errors are false positives, please file a bug against check-webkit-style.

[John Mellor]

Comment on attachment 143381 [details]
Patch

NOT FOR REVIEW! This patch contains the full Font Boosting implementation from Chrome for Android (rebased onto upstream WebKit). This is purely for reference, to give a global overview of how everything currently fits together. I will upload actual patches incrementally, incorporating appropriate cleanups & refactoring (for example I would like to move code out of generic files like Document.cpp into Font Boosting-specific files).

You can try this patch out on desktop Chrome if you set the compile flags ENABLE_FONT_BOOSTING=1 and HACK_ENABLE_FONT_BOOSTING_ON_DESKTOP=1. It will boost all pages as if they were 980px wide and the device-width was 320px. Don't try this on mobile pages (with a meta viewport tag) or you'll get undefined results!

[John Mellor]

(In reply to comment #7)
> (From update of attachment 143381 [details])
> You can try this patch out on desktop Chrome if you set the compile flags ENABLE_FONT_BOOSTING=1 and HACK_ENABLE_FONT_BOOSTING_ON_DESKTOP=1.

Oops, I mean HACK_FORCE_FONT_BOOSTING_ON_DESKTOP=1 not HACK_ENABLE_FONT_BOOSTING_ON_DESKTOP=1.

[Kenneth Rohde Christiansen]

Thanks for posting this! The basic idea seems quite similar to what we did, but I have to dig into all the special cases.

Instead of hardcoding the size of 320 why don't you use the actual CSS width of the viewport. That is what you zoom into when doing double-tap to zoom, and you want to ensure the minimum fonts size when zoomed into exactly that. Wouldn't that not make it testable on the desktop without the current hacks. People will just have to resize the view instead.

[WebKit Review Bot]

Comment on attachment 143381 [details]
Patch

Attachment 143381 [details] did not pass chromium-ews (chromium-xvfb):
Output: http://queues.webkit.org/results/12749479

New failing tests:
platform/chromium-android/fast/font-boosting/various-tricky-cases.html

[WebKit Review Bot]

Created attachment 143401 [details]
Archive of layout-test-results from ec2-cr-linux-03

The attached test failures were seen while running run-webkit-tests on the chromium-ews.
Bot: ec2-cr-linux-03  Port: <class 'webkitpy.common.config.ports.ChromiumXVFBPort'>  Platform: Linux-2.6.35-28-virtual-x86_64-with-Ubuntu-10.10-maverick

[WebKit Review Bot]

Comment on attachment 143381 [details]
Patch

Attachment 143381 [details] did not pass chromium-ews (chromium-xvfb):
Output: http://queues.webkit.org/results/12771044

New failing tests:
platform/chromium-android/fast/font-boosting/various-tricky-cases.html

[WebKit Review Bot]

Created attachment 143425 [details]
Archive of layout-test-results from ec2-cr-linux-01

The attached test failures were seen while running run-webkit-tests on the chromium-ews.
Bot: ec2-cr-linux-01  Port: <class 'webkitpy.common.config.ports.ChromiumXVFBPort'>  Platform: Linux-2.6.35-28-virtual-x86_64-with-Ubuntu-10.10-maverick

[John Mellor]

(In reply to comment #9)
> Thanks for posting this! The basic idea seems quite similar to what we did, but I have to dig into all the special cases.
> 
> Instead of hardcoding the size of 320 why don't you use the actual CSS width of the viewport. That is what you zoom into when doing double-tap to zoom, and you want to ensure the minimum fonts size when zoomed into exactly that. Wouldn't that not make it testable on the desktop without the current hacks. People will just have to resize the view instead.

Yes, there are quite a few similarities.

Since desktop Chrome doesn't have pinch zoom, when testing on desktop I find it easiest to resize the browser window to 980px wide but have the page boosted as if it were being rendered on a mobile device (I'll recompile with a different value instead of 320 to simulate other screen sizes like tablets). If I had to resize my browser window to 320px in order for text to be boosted, I would get a good representation of how unboosted text will look after zooming in, but boosted paragraphs would all be wider than the browser window and there would be no way of "zooming out".

[Kenneth Rohde Christiansen]

(In reply to comment #14)
> (In reply to comment #9)
> > Thanks for posting this! The basic idea seems quite similar to what we did, but I have to dig into all the special cases.
> > 
> > Instead of hardcoding the size of 320 why don't you use the actual CSS width of the viewport. That is what you zoom into when doing double-tap to zoom, and you want to ensure the minimum fonts size when zoomed into exactly that. Wouldn't that not make it testable on the desktop without the current hacks. People will just have to resize the view instead.
> 
> Yes, there are quite a few similarities.
> 
> Since desktop Chrome doesn't have pinch zoom, when testing on desktop I find it easiest to resize the browser window to 980px wide but have the page boosted as if it were being rendered on a mobile device (I'll recompile with a different value instead of 320 to simulate other screen sizes like tablets). If I had to resize my browser window to 320px in order for text to be boosted, I would get a good representation of how unboosted text will look after zooming in, but boosted paragraphs would all be wider than the browser window and there would be no way of "zooming out".

You could try testing with Qt and use the MiniBrowser. It supports emulating touch points (create using ctrl plus mouse button), as well as double tap to zoom and pinch zoom.

[Rich Bradshaw]

As a Web Developer, this is causing me a few issues in Chrome for Android – is there a way to disable it (either meta tag, header or CSS?) - if not, can there be?

This feature means that some paragraphs are huge in comparison to others, and that small text in footers is often bigger than body text!

I'm using Chrome on a Nexus 7 as my reference point btw.

[John Mellor]

(In reply to comment #16)
> As a Web Developer, this is causing me a few issues in Chrome for Android – is there a way to disable it (either meta tag, header or CSS?) - if not, can there be?
> 
> This feature means that some paragraphs are huge in comparison to others, and that small text in footers is often bigger than body text!
> 
> I'm using Chrome on a Nexus 7 as my reference point btw.

Currently the only side-effect free way to disable Chrome for Android's Font Boosting is to set CSS max-height:1000000px on the block that contains the text (any fixed height greater than the actual height will do); setting it on the parent or grandparent block (but not higher up than that) will usually also work.

For example, putting the rule "#footer, #footer * { max-height:1000000px; }" at the top of your CSS would disable Font Boosting for the element with id "footer" and all its descendants (putting this at the top of your CSS makes it easier for subsequent rules that set max-height to override it).

Think carefully about why you're disabling Font Boosting though, and make sure to test on a (portrait) phone afterwards to make sure that your site is still legible. If you disable it on wide blocks of text, users will get tiny illegible text (if they fit the block to the screen), or can zoom in but will then have to scroll from side to side to read each line of text, which is a terrible user experience (unless it's for something short and rarely read like a footer).

A cleaner API will be provided for disabling Text Autosizing (the upstream implementation, which is the subject of this bug; feel free to email me if you have further Chrome for Android specific questions).

[John Mellor]

Mozilla posted a very interesting description of how their Font Inflation algorithm works, going into detail on a bunch of their heuristics:
http://jwir3.wordpress.com/2012/07/30/font-inflation-fennec-and-you/

They've also drafted a spec for the CSS text-size-adjust property that web developers can use to control text autosizing:
http://dev.w3.org/csswg/css-size-adjust/

I recommend that interested parties read their algorithm description. I'll probably try and use some of their heuristics instead of some of the ones I was planning to upstream from Chrome for Android, for the sake of making text autosizing more uniform across browsers (and hence easier for web developers to deal with).

[Adam Barth]

> I'll probably try and use some of their heuristics instead of some of the ones I was planning to upstream from Chrome for Android, for the sake of making text autosizing more uniform across browsers (and hence easier for web developers to deal with).

That sounds great.

[Adam Barth]

This work has progressed to the point where it no longer blocks Bug 66687.  :)

[John Mellor]

The broad strokes of Text Autosizing are now implemented. I'm re-focusing this master bug to track remaining improvements that can be made, and issues that this causes.

[Anton Obzhirov]

Hi, I was wondering if you are going to finish this feature now after the latest news :) I am enabling it for GTK port. We can help to complete it if needed.

[Arvid Nilsson]

(In reply to comment #22)
> Hi, I was wondering if you are going to finish this feature now after the latest news :) I am enabling it for GTK port. We can help to complete it if needed.

The BlackBerry port maintainers are interested in helping to develop this feature.

[John Mellor]

Hi Anton and Arvid!

As expected, avayvod, timvolodine and I will be focusing on Blink for now, but Text Autosizing is fortunate in being very self contained (most code is in TextAutosizer.cpp/.h). Hence I don't expect this feature to diverge as quickly as the rest of Blink, and it definitely seems feasible to keep the Blink and WebKit implementations in sync if you guys are interested in contributing.

In terms of status, this is shipping in stable Chrome for Android with acceptable quality. We're ramping down development, and from now on expect to do a slow but steady trickle of patches to address the most glaring user issues we discover. Bugs reported by users and QA are on the chromium bug tracker, with the Cr-Blink-TextAutosize label:

https://code.google.com/p/chromium/issues/list?q=Cr=Blink-TextAutosize&can=2&sort=pri

[Anton Obzhirov]

(In reply to comment #24)
> Hi Anton and Arvid!
> 
> As expected, avayvod, timvolodine and I will be focusing on Blink for now, but Text Autosizing is fortunate in being very self contained (most code is in TextAutosizer.cpp/.h). Hence I don't expect this feature to diverge as quickly as the rest of Blink, and it definitely seems feasible to keep the Blink and WebKit implementations in sync if you guys are interested in contributing.
> 
> In terms of status, this is shipping in stable Chrome for Android with acceptable quality. We're ramping down development, and from now on expect to do a slow but steady trickle of patches to address the most glaring user issues we discover. Bugs reported by users and QA are on the chromium bug tracker, with the Cr-Blink-TextAutosize label:
> 
> https://code.google.com/p/chromium/issues/list?q=Cr=Blink-TextAutosize&can=2&sort=pri


Hi, 
Yep, we will be definitely keeping an eye on it, I am going to register in chromium bug tracker to follow your updates for Blink and helping bringing those changes to WebKit.

Arvid, what do you think?

[Arvid Nilsson]

(In reply to comment #25)
> (In reply to comment #24)
> > Hi Anton and Arvid!
> > 
> > As expected, avayvod, timvolodine and I will be focusing on Blink for now, but Text Autosizing is fortunate in being very self contained (most code is in TextAutosizer.cpp/.h). Hence I don't expect this feature to diverge as quickly as the rest of Blink, and it definitely seems feasible to keep the Blink and WebKit implementations in sync if you guys are interested in contributing.
> > 
> > In terms of status, this is shipping in stable Chrome for Android with acceptable quality. We're ramping down development, and from now on expect to do a slow but steady trickle of patches to address the most glaring user issues we discover. Bugs reported by users and QA are on the chromium bug tracker, with the Cr-Blink-TextAutosize label:
> > 
> > https://code.google.com/p/chromium/issues/list?q=Cr=Blink-TextAutosize&can=2&sort=pri
> 
> 
> Hi, 
> Yep, we will be definitely keeping an eye on it, I am going to register in chromium bug tracker to follow your updates for Blink and helping bringing those changes to WebKit.
> 
> Arvid, what do you think?

Sounds great! From the way the BlackBerry port uses the FrameView::fixedLayoutSize(), I've found that we'd like to make it possible to obtain the windowInfo.minLayoutSize from a setting, much like it's already possible to get the windowSize from Settings::textAutosizingWindowSizeOverride(). Then we can tweak these parameters from our WebKit layer. Otherwise text autosizing seems to work as advertised =)

I have a question on stackoverflow including example code which demonstrates a Font Boosting problem on mobile Chrome:

http://stackoverflow.com/questions/18422311/long-h1-increases-font-size-of-all-statically-positioned-text-in-mobile-browsers

The problem was indeed fixed by adding "h1,div {max-height: 100000px;}".  Should I file a bug somewhere?  Thank you.

I must say, I think this font boosting heuristic is a total failure.  It routinely results in pages rendering with comical disparities in font sizes, where wide blocks of text, such as forum posts, are ridiculously large, with three words barely fitting across the screen, but the smaller text elements surrounding them (e.g. forum post headers with username, date, etc) are so tiny as to be completely illegible.  Even loading this very bug report page results in this.  I will attach a screenshot.

Created attachment 238157 [details]
Screenshot of this bug page being rendered unusable by font boosting on a high-resolution phone.

Screenshot of this bug page being rendered unusable by font boosting on a high-resolution phone.

Apologies for the blurry image.  Chrome dev tools seems to be resampling the screenshot.  However, it's actually fairly representative of how usable that text is when rendered so small on my phone.  The normal sized text is so small you are forced to zoom, but the font boosting has made the other text so absurdly large that zooming is counterproductive.

[mishamsk]

Found yet another bug with this. Full description here: http://stackoverflow.com/questions/27473365/how-to-keep-fonts-consistent-and-respect-text-scaling-on-android-bizarre-bug-of

Basically font scaling stops working when <h6> contains more than two anchors inside (did not check for other header tags)

[Daniel Bates]

I removed the ENABLE(TEXT_AUTOSIZING)-guard code in <https://trac.webkit.org/changeset/206119> (bug #162167) because there was neither a port that enabled it by default nor a Buildbot on build.webkit.org that built with this feature enabled. Although the ENABLE(TEXT_AUTOSIZING)-guard is somewhat self-contained it has not seen active development in some time and it does add noise to the codebase where its machinery hooks into the DOM, style and layout subsystems. An analogous feature is enabled by default on Mac and iOS, IOS_TEXT_AUTOSIZING (we should rename this feature).

We should look to remove any Mac/iOS dependencies from the IOS_TEXT_AUTOSIZING code or start a new attempt at implementing a platform-independent automatic text size adjustment feature. Such an effort may resurrect some or all of the code removed in <https://trac.webkit.org/changeset/206119>. Regardless, we should ensure that any code changes for this feature are built by at least one port with a public facing Buildbot.