[css-fonts] consider not making font-min-size and font-max-size affect font-size computed value

[emilio]

Spec: https://drafts.csswg.org/css-fonts-4/#propdef-font-min-size

I think these two properties should only affect the used font-size value, not the computed one.

It's a bit weird that, as specified, font-min-sizes computed value affects font-max-sizes used value, but font-sizes computed value.

Affecting the computed value implies that it also affects font-relative lengths. This causes unintended consequences when users override it with a larger font size, like:

https://bugs.chromium.org/p/chromium/issues/detail?id=937689

In Gecko the user-preferred minimum font-size only affects the used font-size, which I think has less potential to break websites.

[emilio]

https://bugs.chromium.org/p/chromium/issues/detail?id=944002 is another example of site broken on chromium when overriding author preferences.

[fred-wang]

Another argument in favor of this proposal is for the implementation of math-script-level ( #31 ). The computed font-size can be decreased/increased by increasing/decreasing the script-level. This can be reverted by decreasing/increasing the script-level by the same amount. However, that's no longer possible if the computed font-size is clamped by font-min-size/font-max-size when it goes below/above the min-size/max-size.

[litherum]

@fantasai

[svgeesus]

I saw this counter-argument on the chromium bug:

Our behavior here is intentional, we choose to respect the users minimum font size over what the site has specified. This is an accessibility feature and we consider legibility to be the more important consideration in this case.

However, respecting the users minimum is not the issue here. As @emilio said:

In Gecko the user-preferred minimum font-size only affects the used font-size, which I think has less potential to break websites.

[fantasai]

If an author is using em and rem units correctly (i.e. for things that should scale with the text), then they need to match the font size that is actually in use. E.g. line-height: 1em will overlap text if you resolve ems before applying font-min-size. Likewise paddings, margins, and images designed to be multiples of the text size should be keying off the actual used font size and not some theoretical value that's not being used.

[css-meeting-bot]

The CSS Working Group just discussed font-min/max-size and computed value, and agreed to the following:

• RESOLVED: Remove min-font-size and max-font-size from Fonts 4, replace with an example of using clamp() to handle safe responsive typography.

The full IRC log of that discussion

<TabAtkins> Topic: font-min/max-size and computed value
<fantasai> I've updated https://wiki.csswg.org/spec/publish with the blanket publication resolution
<fantasai> fwiw
<astearns> github: https://github.com//issues/3739
<TabAtkins> emilio: Browsers have minimum font-size settings for a11y
<TabAtkins> emilio: And they work differently in WK-based vs Firefox
<TabAtkins> emilio: WK-based browsers, it affects the font-relative units.
<TabAtkins> emilio: In Firefox they do not.
<TabAtkins> emilio: So I was considering implementing min-font-size, and that affects the computed value of font-size, I would assume
<TabAtkins> emilio: So first, the a11y setting in Blink can break websites
<TabAtkins> emilio: I'd also like min-font-size to work the same as the a11y setting.
<TabAtkins> fantasai: Reason it affects computed and not just used font size is that if you were using ems correctly (for the purpose of making something relative to text size), then everything should scale and match the size of text.
<TabAtkins> AmeliaBR: How much would things break if we declared a different computed value for inheritance vs font-relative units?
<TabAtkins> dbaron: Which is what I thought Gecko did, and maybe what it did pre-servo
<TabAtkins> fantasai: That would be fine and would honor the constraint we want
<TabAtkins> emilio: Would it?
<TabAtkins> [Amelia re-explains their proposal]
<fantasai> TabAtkins: So on any given element, 1.2em would still be 120% size of the text
<TabAtkins> emilio: That would still break websites if we used this to ipmlement the a11y setting
<fantasai> dbaron: ...
<TabAtkins> dbaron: I think this is mostly problematic because of people misusing rem to get a custom-sized unit
<fantasai> s/.../people use the root font size to create a unit that's not really related to the font size, and that breaks if you apply font size minimums to it/
<TabAtkins> jensimmons: And they want nice math, yeah
<dbaron> s/mostly/also significantly/
<TabAtkins> myles_: So it sounds like users are getting min-font-size via the UI settings; could you just keep that separate from min-font-size property?
<TabAtkins> emilio: Yeah, we could. But it would still mean the minimum font size setting is magical; you couldn't override that in a user stylesheet.
<TabAtkins> dbaron: Also one of the underlying principles of CSS is that it explians how author and user expectations work with each other. Settings/prefs are usually explained as part of the user stylesheet.
<AmeliaBR> q+ to talk about author use of min/max-font-size
<TabAtkins> myles_: Right. There just might be a distinction between an author saying they want to scale up a font size, and the user saying they can't see text smaller than a certain value.
<TabAtkins> dbaron: Also, minimum font sizes don't seem to work well in practice anyway, many pages break. So maybe this isn't the most useful anyway.
<TabAtkins> fantasai: So if authors do understand the unit and use things correctly, things should still scale correctly.
<TabAtkins> jensimmons: So to clarify, there's a min/max-font-size, and maybe you set font-size with a calc(vw) or whatever.
<TabAtkins> jensimmons: So if you hit a min or a max, and we cap it when you hit the limit, should that propagate to the 'em' unit, that's the question, right?
<chris> yes, exactly
<TabAtkins> [yes]
<TabAtkins> jensimmons: It doesn't even make sense to me that it wouldn't transfer over.
<florian> +1 to jensimmons
<astearns> ack AmeliaBR
<Zakim> AmeliaBR, you wanted to talk about author use of min/max-font-size
<fantasai> /So/CSS provides a variety of units to allow authors to express the why of their sizes through relative measurements, against the font or the screen or the container or the pixels, etc. Authors who understand these units will use font-relative units when they want things to scale with the font, so/
<TabAtkins> AmeliaBR: So while CSS gives people the tools to use things properly, we have to recognize that some people won't use it correctly.
<fantasai> jensimmons gives an example of e.g. gmail which doesn't handle the scaling of text correctly, so zooming in creates a suboptimal layout -- but this is a case of the author not choosing to use the correct units ; breaking the connection between ems and font-size would make it impossible to fix
<TabAtkins> dbaron: I think I agree that making 'em' honor min/max is the only thing that makes sense. It's not clear to me which to go with inheritance, as it depends on use-case
<TabAtkins> fantasai: There was a comment from Fred Lang, where if min/max clamped the value before inheriting, you'd have a size in the multi-step process that gets messed up and messes up all subsequent sizes.
<leaverou> Agreed with dbaron. Authors use ems assuming they correspond to actual used font size. If that assumption breaks, a lot of UIs would too.
<dbaron> s/Lang/Wang/
<fantasai> fantasai: So I agree with Amelia that the computed / inherited font-size should not be affected by the min/max, but that the min/max should factor into not just the used font size but also the resolution of font-relative units
<fantasai> fantasai: We would be doing authors a disservice if we did not ensure that the font-size and 1em matched.
<astearns> ack dbaron
<chris> I agree with that proposed solution
<chris> ... otherwise things end up double-applied, growing too much
<TabAtkins> dbaron: I think this is a reasonable conclusion, I think it doesn't work well for Jen's use-case, but I think what does work well for that is using min()/max() inside of font-size.
<chris> ... clamping should happen as late as possible
<TabAtkins> dbaron: Because you want clamping to happen at a particular point, not to be inherited down further into the tree. So you'd use `font-size: clamp(10px, ..., 36px);`
<TabAtkins> AmeliaBR: Right, and that would be bad for min-font-size, as then a `<small>` child would also get clamped and not get smaller. While clamp() works properly
<chris> q?
<chris> q+
<heycam> q+
<astearns> ack chris
<TabAtkins> chris: THis has been interesting. Not sure I could reproduce this aftera few days. I want some examples in the spec of what you should use each with.
<AmeliaBR> +1 to examples!
<heycam> q-
<fremy> (side note for people interested in this and would love examples, Jason Pamental talk at cssconf this year is a great resource)
<iank_> q+
<TabAtkins> TabAtkins: I think we're leanign toward the properties being designed purely for the a11y/settings use-case, and if you want to just clamp a value in a range, you should always use the math functions.
<astearns> ack iank_
<TabAtkins> iank_: Currently the way we do this in Blink for a11y isn't via a property because the font-size clamping we do applies on a per-region basis.
<TabAtkins> myles: Ours is also complicated, probably in a different way.
<TabAtkins> myles: It seems like dbaron was saying the function of CSS was to explain browser features. It sounds like this feature shouldn't be explained in CSS, and it should remain magic.
<TabAtkins> emilio: It sounds like Ian is talking about the text auto-sizing actually?
<TabAtkins> myles: Ah, but I wasn't in mine.
<TabAtkins> myles: We have a lot of systems that interact to produce a text size.
<TabAtkins> myles: I've spent a long time trying to increase readability, and...
<TabAtkins> myles: The issue is "I want to use this CSS feature to do a11y, but things break", then we just shouldn't use that feature.
<TabAtkins> florian: So what are we using these for?
<fantasai> myles: These were added before my time...
<TabAtkins> myles: These predate me, there was just a note in the spec and I started implementing
<TabAtkins> TabAtkins: These predate the math functions; they were meant to implement the "keep vw-based font sizes from getting too big/small"
<TabAtkins> TabAtkins: So we can just drop the properties, then
<TabAtkins> chris: I was looking at history; this looks like something that was dropped from Fonts 3, and Myles dropped it into Fonts 4 two years ago.
<tantek> agreed with TabAtkins
<tantek> proposal: drop the properties because not implemented anywhere
<TabAtkins> astearns: So these aren't implemented in a user-facing way anywhere, and we're not convinced they're good for any use-case...
<tantek> jensimmons: responsive typography is what the use-case is called, you can search for it
<fantasai> https://lists.w3.org/Archives/Public/www-style/2014Jun/0187.html
<AmeliaBR> `font-size: clamp(12px, 10vmin, 24px)` vs `font-size: 10vmin; min-font-size: 12px; max-font-size: 24px;`
<TabAtkins> astearns: So looks like we have consensus to remove these properties, until we have a use-case that min()/max()/clamp() don't serve.
<TabAtkins> AmeliaBR: And replace the section with an example of how to use clamp()l.
<tantek> aside: how do we do copy-fitting
<TabAtkins> RESOLVED: Remove min-font-size and max-font-size from Fonts 4, replace with an example of using clamp() to handle safe responsive typography.
<tantek> q?
<chris> q?
<TabAtkins> heycam: The effect of these properties on the computed value of font-size... still worth resolving on how these browser settings affect things?
<fantasai> ChrisL: Example of broken is page with <html style="font-size: 1px">. Answer is, don't do that.
<fantasai> TabAtkins: The way it inherits separately is a problem for designing a font hierarchy relative to a base size, tho
<fantasai> AmeliaBR: Should we give advice to browsers on whether font-relative units should be affected by browser settings?
<fantasai> myles: Arguments on both sides
<fantasai> myles: If we don't expose to authro, they don't know what happened to their page
<fantasai> myles: I don't think it should be specced
<TabAtkins> TabAtkins: Note tho that h6 defaults to smaller than standard font size. If min-font-size is set to standard-font-size (both 16px, say), and you defined your hX hierarchy by starting from h6 size and then calc()ing up the higher values, the Chrome behavior would mess things up; starting from h1 and calc()ing down would be fine. So it's not *all* pathological cases.
<astearns> ack dbaron
<TabAtkins> dbaron: To respond to myles there's another tradeoffs around a11y
<TabAtkins> dbaron: Some users that need a11y are concerned about privacy, and are willing to have the feature not work as well to keep secret that they're using it.
<TabAtkins> TabAtkins: For this feature, no matter how you do it it'll be page-exposed tho
<TabAtkins> dbaron: Also, the browser minimum isn't *really* a minimum.
<TabAtkins> dbaron: If you specify a min of 10px to font-size:1px, you get 10px font. But applied to font-size:0px, you get 0px. That's very important. So it's not a strict "minimum" anyway.
<fantasai> myles: Example is layout with inline-blocks, set font-size: 0px so that the gap below the baseline is zeo.
<TabAtkins> TabAtkins: Myles, wanna capture that 0px point in the spec? If everyone agrees something is needed for webcompat, it should be captured
<TabAtkins> myles: In a note, sure

[fred-wang]

In Gecko the user-preferred minimum font-size only affects the used font-size, which I think has less potential to break websites.

I removed the math-script-level tests for font-min-size and font-max-size and instead replace it with a test to check interaction with user-preferred minimum font-size: web-platform-tests/wpt#17228