Allow for deterministic control over "font floors" and Text Autosizing thresholds

[sadym-chromium]

Addressing part of #772.

The Problem: Non-Deterministic Rendering due to Hidden Font Constraints

Browser engines implement internal rendering heuristics that can override CSS font-size declarations. These mechanisms are implementation-defined with specification based on minimum readable text size, creating significant cross-browser and cross-platform inconsistency:

• Implicit "Font Floors": Engines enforce a minimum size below which text will not shrink. These defaults vary by host OS, locale, and language settings, making visual tests non-reproducible across different CI environments.
• Environment-Specific Scaling: Mechanisms like Blink's TextAutosizer use heuristics that depend on the viewport context. Without a way to synchronize the "minimum readable" threshold, identical code can produce different layouts (line-wrapping, container heights) on different machines.

Proposal: Allow for overriding minimum readable text size

We propose adding a new command browsingContext.setMinimumReadableTextSize.This command will allow clients to override environment-specific defaults of minimum readable text size.

[css-meeting-bot]

The Browser Testing and Tools Working Group just discussed Text sizing.

The full IRC log of that discussion

<AutomatedTester> topic: Text sizing
<AutomatedTester> github: https://github.com//issues/1051
<sadym> the consensus: move it to the dedicated command and allow for setting the default and returning "unsupported" if so
<tidoust> sadym: Minimum readable text size. It's different in different browsers. It tells what is the smallest a readable text can be.
<tidoust> ... I'm going to update the issue description.
<AutomatedTester> q?
<sadym> q+
<AutomatedTester> ack next
<tidoust> sadym: This specification is CSS specification, and it can take a long time to change. Are we fine with landing WebDriver BiDi first with hooks to it and wait for CSS to adopt it?
<jgraham> q+
<tidoust> ... Or do we want to land the BiDi command only when the CSS hooks are approved or pre-approved.
<AutomatedTester> ack next
<sadym> q+
<tidoust> jgraham: I think we'll need to look what implementations do here. I don't know if minimum text size is a good characterization, or if you need text inflation, or if it's more complex than that.
<tidoust> ... I don't know enough details to make a call on this.
<AutomatedTester> ack next
<tidoust> sadym: We want this unified across the browsers. For sure, we have different engines working differently. We can use that command to do additional logic to emulate things further, which isn't required by CSS.
<jgraham> q+
<AutomatedTester> q?
<AutomatedTester> ack next
<tidoust> jgraham: Very quickly, there seem to be 4 different values in the code. The command could be setting mobile text layout for example. By default, the browser has to pick something that is appropriate to the context.
<AutomatedTester> q?
<sadym> q+
<AutomatedTester> ack next
<jgraham> q+
<jdescottes> q+
<AutomatedTester> ack next
<tidoust> sadym: No split between specific answers.
<tidoust> jgraham: That does not seem like a good idea.
<sadym> q+
<tidoust> ... For the font size inflation that browsers do on mobile, that seems fine.
<AutomatedTester> ack next
<tidoust> ... I don't think it should affect other mobile emulation stuff.
<tidoust> jdescottes: If we don't have a strong spec that we can hook into, we should not try to add behavior that only Chrome would implement.
<tidoust> ... I think this command should still do something that can matched to a spec and by all browsers as much as possible.
<AutomatedTester> ack next
<tidoust> sadym: So consensus is to introduce a command, emulateMobileTextLayout with implementation-specific logic behind it.

[gsnedders]

It's distinctly the case that the CSS Mobile Text Size Adjustment Module is incredibly vague and not really suitable to base implementations off, and I don't think we can realistically built on top of it. See, e.g., w3c/csswg-drafts#4435 which significantly rewrites it.

As that PR hints at, existing behaviour can depend on many different things, and it seems kinda unclear quite what the goal is here.

Letting UAs potentially just "emulateMobileTextLayout" in a very broad implementation-defined way is perhaps as good as anything else, though obviously a desktop-only UA might not support text-size-adjust at all.