Also see #731 #6371 etc. There have been changes to font-size-adjust recently which may be enough to cover your use case.

Also, ex height is really only meaningful for Euroscript (Latin, Greek, Cyrillic, somewhat for Armenian and Georgian), which of course collects a lot of landowners and wollen text out there.

PS 2024: I just read my comment from three years ago and couldn’t tell what the last clause (“landowners and wollen”) was meant to say before autocorrect mangling.

Hi Christoph @Crissov

Also see #731 #6371 etc. There have been changes to font-size-adjust recently which may be enough to cover your use case.

I reviewed them, but it's really not an intuitive way to set a font size, and does not solve the problem from an accessibility guidelines perspective.

What is needed is to be able to set the font size at a specific x-height directly, i.e. as the examples I provided above. This has been a project over here since 2019, associated with the visual contrast work that is part of WCAG 3.

There is probably still a place for font-size-adjust but it seems like it's for a different use case.

At the moment the only implementation is Firefox, all other browsers have dropped support for it. Using the Firefox implementation there are unexpected behaviors such as with line-height and em units, which I discuss above and on the samples page. But even is some of those are fixes, it is not an intuitive way to define a font height for a standard — it's confusing and cumbersome.

Also see #731 #6371 etc.

I saw your post regarding a font-size for the @font-face, and I was working on something similar, as yes that is needed too.

And where these are leading:

In addition to needing to set a specified size for accessibility guidelines, there are needs regarding text zoom and reflow.

I'm getting ahead of myself here, but what is needed for text zoom is on this page: https://www.myndex.com/WEB/TextZoomExample

What is needed is not a zoom by percentage, but to a specific text size, where the smallest text is zoomed up to the needed size, but larger text on the page is zoomed only enough to maintain a position as "larger" even if larger by only 1 px. And the starting and ultimate size is defined in px, not as a percentage. And that px needs to relate directly to x-height.

Just an example — there are a lot of other properties needed to help define meaningful standards and guidelines for readability, but many of them rest on this basic one of setting x-height with a length, either absolute (px) or relative (em).

Also the name, font-size-adjust seems like it should be for a different purpose (such as user style sheet adjust-without-override which is also needed). At the moment "user style sheets" are fairly useless, as they completely over-write the author's CSS for those properties, resulting is a lot of breakage. For a useful user style sheet, it would oly adjust and not over write. But again, that's for another thread.

Instead of font-size-adjust it seems like it should be x-height-ratio because that is essentially what it's doing.

Also, ex height is really only meaningful for Euroscript (Latin, Greek, Cyrillic, somewhat for Armenian and Georgian), which of course collects a lot of landowners and wollen text out there.

That's sort of like saying "it only applies to people with computers"... And ultimately not entirely true, as many alphabets are structured with glyphs at different sizes. — I believe this is going to be important for Korean fonts for instance.

BUT that's not the actual point.

Here is the point: A font has a body size, usually large enough to contain all the glyphs and ascenders and descenders, and perhaps swashy embellishments etc. Setting the font size does not relate directly to the glyph size in a standard way (as I've shown). This is true in other scripts even if it does not have upper/lower case.

What is important for readability guidelines is to be able to specify how big a glyph is rendered to the screen, not the font body size which contains whatever amount of empty space.

There is no standard for glyph size nor weight, nor anything else, really. These values vary not only per foundry, but even in the same foundry with different families. As a result, creating a guideline that "minimum font size..." is literally meaningless — unless it is directed at something that can be measured and results in a (somewhat) consistent size rendered to screen.

For latin scripts, we know that the critical size for fluent readability at 20/20 is an x-height of 9.4px. That might be possible with a 16px font size using Verdana, or you might need an 18.8px size... for Times New Roman you need the font size at 21px to achieve that critical size.

Thank you,

Andy

A TL;DR Summary:

• font-size: is not a "best way" to set a font size.
  • The ultimate results on screen will vary depending on the font family.
  • It is impossible to change the behavior of font-size: due to existing usage of course.
• font-x-size: for setting font based on x-height is intended as a REPLACEMENT for font-size:
  • It will allow better control of how latin and similar fonts render on screen.
  • The companion font-cap-size: gives more direct control of upper case rendered size.
  • font-abs-size: as a companion for other languages with no case, to provide control of the absolute rendered size.
• ex-to-em is a companion to provide affirmative control of the em unit when font-x-size: type properties are in use.

Other critical metrics for readability are font weight, leading (line-height), tracking (letter-spacing), and kerning. There is no effective standard how size nor any of these result in a particular family rendering to screen.

These are among the most critical accessibility failures facing web content today.
(Along with the mistaken belief that "4.5:1" is adequate contrast for body text, which it is not.)

Thank you,

Andy

PS: Here's a chart that outlines critical reading size, based on visual angle, which references the research of Dr. Lovie-Kitchin on critical size for readability. As a statistical reference, only about 45% of the population is at or better than 20/20. "Impairments begin at 20/20" you might say. The average and median acuity is about 20/40 (which is the limit in all 50 states for a non-commercial drivers license). "Low vision" is 20/70 and worse, and "blind" is 20/200 and worse.

Thoughts on having a mode switch like box-sizing but for font sizing?

p {
  font-sizing: ex;
  font-size: 1.2ex;
}

would be equivalent to

p {
  font-size: 1.2em;
}

All the units would be the same. This would only change the behavior of font-size making it apply to x-height instead of em-height. The idea is that this follows precedent of changing modes in CSS and reduces possible confusion if both font-size and font-x-size are used in the same ruleset.

Like box-sizing this should’t inherit.

Some more possible things to explore:

This could also incorporate what @fantasai has done with the text-edge property, allowing finite control over what metrics are used beyond just x-height to size text.

Hi Scott @scottkellum

Thoughts on having a mode switch like box-sizing but for font sizing?

p {
  font-sizing: ex;
  font-size: 1.2ex;
}

I like this the more I think about it, actually makes a lot of sense to make it a switch like this. We pretty much never used x-height in traditional print.... We need set size with x-height now because the web is not fixed in place like print, it's always dynamic and always changing.

My concern is the amount of breakage this can do, at least until the property is widely adopted. How would it fallback for browsers the don't support it...?

A reason I was suggesting the property as above is that fallback would be easy:

  div { 
    font-size:  21px;  
    font-x-size:  12px;  
  }

This assumes of course that font-x-size: always overwrote font-size: for supported browsers.

All the units would be the same. This would only change the behavior of font-size making it apply to x-height instead of em-height.

  div { 
    font-sizing: ex;  
    font-size: 12px;  
    border-width: 1em;
  }

In this case what would the border width be? 12px, 17px, 23px, or 24px?

What if font-sizing: ex had an additional numeric property?

font-sizing: ex 0.52; where the number is the relationship of the x-height to the em size x-height is about 0.52 for Helvetica, so in this example it will bring the font back to the em size..... Or perhaps that should simply be the default...

My concern is the amount of breakage this can do, at least until the property is widely adopted. How would it fallback for browsers the don't support it...?

This is why I think it shouldn’t be inherited like box-sizing. You can implement it globally with the * selector, but you have to explicitly make that decision knowing it may break some things.

Additionally @supports will let you progressively enhance your code. I’m going to start using px in these examples to more clearly illustrate how things work, but relative units are always best practice.

div { 
  font-size:  16px;  
}
@supports (font-sizing: ex) {
  div { 
    font-sizing: ex;
    font-size: 12px;
  }
}

In this case what would the border width be? 12px, 17px, 23px, or 24px?

In your example:

div { 
  font-sizing: ex;  
  font-size: 12px;  
  border-width: 1em;
}

It depends on the font used, but assuming a ratio of 0.52 for Helvetica, then the border should be about 23px.

font-sizing: ex 0.52; where the number is the relationship of the x-height to the em size x-height is about 0.52 for Helvetica, so in this example it will bring the font back to the em size..... Or perhaps that should simply be the default...

As it is so rare that a font provides the ability to adjust the x-height, I think this might be out of scope for this spec. When that adjustment is available, the variable font axis is unregistered. If a font author wants the x-height to be adjustable, they can do that now by letting people set it with CSS like font-variaiton-settings: 'XHGT' 0.52. Roboto Flex calls the x-height axis “Lowercase Height”.

Additionally, the variability of x-height is part of the point of having a feature like this in my view. Currently the only way to do this is create a table and do this with a tool like the web font loader. Allowing font sizing via x-height is a tool to work with this variability instead of lock it to a specific ratio.

Here is an excellent video on the need for font-sizing by x-height from @chrisarmstrong.

I've always wanted to be able to specify the size of x-heights and cap-heights in CSS without having to know a font's internal font metrics ahead of time. This desire has only become stronger now after being able to do something like that in newer versions of Adobe Illustrator (which also offers the "ICF box" as a font-sizing option for East Asian CJK typography). The new-ish text-box-trim and text-box-edge properties in CSS also open up a lot of related possibilities for precise typesetting.

As such, I've always longed for something like x-height-size and cap-height-size properties. But actually, @scottkellum’s proposal of specifying alternate non-em anchors for the font-size property would also be quite handy. Perhaps there's a more intuitive/self-descriptive name than font-sizing though? Maybe something like font-size-anchor? font-size-basis? Or adapt terminology from Adobe and call it font-size-reference?

Something like Scott's proposed property would be even more powerful if it could be more than just a numberless unit. For example, instead of font-size-reference: ex, why not also allow for font-size-reference: 2ex, font-size-reference: 1.5cap or font-size-reference: 4ch? You could get even more advanced by allowing for calc() values to factor in several internal font metrics together.

Either way, I don't think the ideas of simple properties like x-height-size and more advanced font-size-reference properties are mutually exclusive, and could override each other the same way other related properties do.

One clarification that would have to be made with something like font-size-reference is if/how it affects the interpretation of 1em. It’s a bit of an Existential Type Question: Is 1em always equal to the font-size, or is the font-size just equal to 1em by default?

I tend to lean toward the latter because 1em is a very specific distance defined within a font's internal metrics, and that distance may still be useful even if the default reference for font-size changes. (For similar reasons, I’m not as excited about the idea of an ex-to-em property as proposed previously.)

@nicksherman My opinion on the relationship between font size and 1em:

• 1em should always equal the full design space height measurement in font itself. This is the size of the em according to the font metrics.
• font-size can be a little more malleable. You can define the font size by x-height, em height (default) or maybe we can throw things like cap-height in there as well. 1em, 1ex and other units based on font metrics will still correspond to those font metrics.

I’m trying to think of ways to not mess up relative font units when doing this and I think font-size is going to be the thing that needs to give to preserve font relative units.

Hi Nick! @nicksherman

Glad to see there is still interest here—this conversation has obviously been continuing for years...

I've always wanted to be able to specify the size of x-heights and cap-heights in CSS without having to know a font's internal font metrics ahead of time.

Me too. Among other things, creating design guidelines that are consistent is challenging when the technology itself is completely inconsistent! The way things work, the browser developers need to incorporate the features into their browsers before it will do us any good.

ex-to-em

..._Perhaps there's a more intuitive/self-descriptive name than font-sizing though? Maybe something like font-size-anchor? font-size-basis? Or adapt terminology from Adobe and call it font-size-reference?

In my first post at the top, I did—I call it ex-to-em: and there are a number of examples in that post of how to use it with font-x-size: to gain predictable control of the apparent size a font rasterizes to screen. See the first post for the examples.

It's Not Just for Convenience

User personalization is the holy grail of accessible interactive design. But you can not have good personalization unless you have technology that is perceptually uniform, and provides predictable results, able to accommodate any given person's user needs.

This Means:

• The user can increase or decrease the overall contrast by a perceptually uniform amount, so the designer's intent for the visual hierarchy is not lost.
• The user can swap out the font family without breaking the layout, but also, while maintaining or enhancing readability.
• The user can choose from a variety of color schemes, including multiple Dark modes, Daltonized modes, and modes specifically tailored to user needs.
  • On this last point, it's labor intensive for a designer to create multiple schemes: with perceptual uniformity, alternate schemes can be created programmatically, with minimal (or no) need for designer labor to create.

The Buck Stops a Bunch of Places

Right now, web standards like WCAG are relying on the author and content creator—but many of the user needs are really only achievable when incorporated into the technology (i.e. the user agent or browser).

Arguably, WCAG should not be relying on content authors to effectuate all of the accessible accommodations needed. Years ago when W3C WAI attempted to develop standards for browsers & the technology, developers were less than enthusiastic The politics of international standards can be.... eh.... nefarious. As a result, WAI created WCAG, saddling content creators with some tasks that would be better served by mature technology.

Some Stuff Have We, Yes?

Progress is being made, but we are a long way from the ideal of automated and robust personalization-on-demand for all. Some things that would be very helpful is supported or better supported by the technology:

• Set font-size per the actual rasterizing size.
  • font-x-size: is a step in that direction—setting size by x-height does a lot to improve consistency.
  • Add in proportional text zoom, so large text zooms up less than small text, and doesn't get unwieldy.
  • Use ex-to-em: to make the relative em value consistent relative to the font in use.
• Set font weight per the perceived rendered weight.
• Enable optical kerning.

And all these features help to enable better text reflow and responsive design, so users can adjust to their needed text size without breaking the layout.

Thank You,

Andy

_{Andrew Somers}
Director of Research
^{Inclusive Reading Technologies
APC—Readability Criterion}

Have you considered the font-size-adjust property?

If you set font-size-adjust: ex-height 1.0, the chosen font will be scaled so that its ex-height equals the font-size.

For example:

data:text/html,<div style="font: 12px Arial; font-size-adjust: ex-height 1.0">Comparing Arial, <span style="font-family: times new roman">Times New Roman,</span> <span style="font-family: impact">and Impact</span></div>

Without font-size-adjust, these fonts would have very different visual sizes.

Hi @jfkthame

Yes, and wrote about it in my posts above.

• “….these are not the properties you’re looking for..”

It really does not work in a way that’s useful IMO. And moreover it’s not supported in a useable way.

It is not the answer. I have some links above to demo pages, which present some of the fundamental issues we’re discussing.

And if we are going to push browser developers to incorporate something like this, let’s incorporate it in a way that’s easy for designers, requires no math, and is intuitive. “Font-size-adjust” is not that.

While font-size-adjust has gotten somewhat worse in support (I did not realize it stopped working in Chrome, that's frustrating), it's still better than the zero browser support that a new property would have. You can't solve "lack of implementation" by adding a new, as-yet-unimplemented-either feature. We should only change the feature if we think the current design is bad and could be done better.

Rereading your posts (apologies, skimming your original post; it's quite long), I don't immediately see a meaningful difference between font-size-adjust and font-ex-size. They both do exactly the same thing - cause the font to render at a particular size such that its x-height matches a given length. The only difference is whether they specify that length directly (as in your proposed font-ex-size) or as a fraction of the font-size (as in font-size-adjust). Can you briefly explain why you think one works better than the other?

font-size-adjust has the additional benefit that, as it's named and designed in a size-agnostic way, one can adjust the font-size relative to other metrics, like cap size. With font-ex-size, you instead need to define a separate font-cap-size, and define which one "wins" when they're both specified. (And in either case, they have to "win" over font-size, meaning they function as a mode switch - you have to know that the element is currently having its font size set by font-ex-size rather than font-size, and either use the matching property, or reset it so you can use a different property.)

(Instead allowing the font-size property to take a keyword along with a length (font-size: 8px ex-size;) would have been an alternate way to go that doesn't have this "mode switching" problem. It was indeed proposed; it was decided against, in favor of font-size-adjust, to ease adoption pain, since generally the size adjustment should be small relative to the "normal" font-size, and so continuing to use the normal font-size in downlevel user agents would be acceptable. I somewhat disagree that this was a great decision, and we could revisit it, but that, too, would have the same "defining a new unimplemented feature to fix another feature not being implemented yet" issue.)

What appeals to me about this proposal over font-size-adjust is that you don't have to know about the metrics of a font to normalize their appearance. Setting font size by x-height directly is not just more straightforward, but also works more consistently for more complex font stacks and fallbacks.

I do have disagreements with this proposal. Font-x-size and font-cap-size along with the font-size property seem to imply these metrics can be controlled individually. The ex-to-em property is more explicit about this font proportion adjustment. My understanding of this means new font tech would need to be created, standardized and widely adopted to reliably implement this. This is why I proposed a toggle that changes what metric font-size uses in thread.

To wrap up, a way for authors to explicitly say what the x-height size of text is would be useful.

Edit: I do think font-size: 8px ex-size; solves the issue well. Interesting to me to hear font-size-adjust was intended to solve this issue. Reading more into it I can see how it can do this, a little awkward but thank you for bringing this up.

Hi @tabatkins thanks for the comment, my reply:

While font-size-adjust has gotten somewhat worse in support, it's still better than the zero browser support that a new property would have.

I would usually disagree, simply from the standpoint that it's been bashed around for years without being adopted. Though I do see that last year Safari added it, so maybe there's hope for it after all.

You can't solve "lack of implementation" by adding a new, as-yet-unimplemented-either feature.

A bit of a strawman argument, especially if the lack of adoption is because it's difficult to implement, or causes unexpected problems, or is confusing to use.

We should only change the feature if we think the current design is bad and could be done better.

That was the premise of my first post here.

....difference between font-size-adjust and font-ex-size. They both do exactly the same thing...

But they don't. One sets character height by font-size: but requires a reference (somewhere) to a ratio set in font-size-adjust:, while 'font-x-size:' directly specifies the character height.

Can you briefly explain why you think one works better than the other?

Designers have expressed to me directly that "no math" is best. font-size-adjust relies on a round-about way of setting font-size to render at a specific x-height, regardless of font. It is not done by setting the x-height directly, but by indicating a ratio, then separately setting the font's body size.

If you're a developer, that nuance may not seem relevant. In my first two posts here, I laid out the reasons I found at the time that it is relevant. Some perhaps can be fixed within FSA.

Was just looking at the example page from a while ago testing font-size-adjust: some things (like the ex unit) don't seem to work predictably, at least not how I expected—I haven't dug into what's causing it to see what's up: https://www.myndex.com/WEB/xheightExample#three

font-size-adjust has the additional benefit that, as it's named and designed in a size-agnostic way, one can adjust the font-size relative to other metrics, like cap size.

'font-size-adjust: cap-height 0.73;' doesn't work on Safari, not yet anyway.

With font-ex-size, you instead need to define a separate font-cap-size, and define which one "wins" when they're both specified

If they both win, that means independent control of the upper case and lower case glyphs. Then, perhaps that indicates a font-num-size: could be added?

But again, these are straw arguments, because it makes no difference if you have:

/* With Fallbacks — unsupported browsers fallback to font-size*/

p {
  font-size: 16px;
  font-x-size: 9.4px;
  font-cap-size: 11.5px;
}

VERSUS

/* With Fallbacks — unsupported browsers fallback to font-size*/

p {
  font-size: 16px;
  font-size-adjust: 0.52;
  font-size-adjust: cap-height: 0.715;
}

font-size-adjust: does not uniquely solve anything here.

The difference between these two scenarios is that font-x-size: allows setting the x-height directly, which is most intuitive, and best for code readability.

...allowing the font-size property to take a keyword along with a length (font-size: 8px ex-size;) would have been an alternate...

I like this better than font-size-adjust:, but font-size: 8px ex-size; still breaks when not supported, still needs a fallback. They all need to be setup with some sort of fallback.

A key advantage of setting the x-height directly relates to guidelines and testing against standards. Setting directly eliminates ambiguity. Using font-size-adjust: there's no direct indication anywhere what the actual x-height is as rendered.

font-size-adjust: is disconnected from font size, which has advantages and disadvantages.

Advantage: You can put font-size-adjust: in the :root {} or body {} declaration, so it applies globally.

Disadvantage: Putting font-size-adjust: in the :root {} or body {} declaration, or elsewhere up the cascade means it's possible for font-size-adjust: to have a different specificity than some specific font-size: setting. It's one more thing that can cause unexpected behavior. Trying to use it globally means it has to be called and set to none for all the instances it's not desired.

font-size-adjust: is inherited, which is good...and bad. Say you have:

article {
  font-size: 16px;
  font-size-adjust: 0.52;
}

Everything inside that article will get that x-height. But what if:

blockquote {
  font-size: 21px;
  font-family: TrajanPro;
}

And the HTML is:

<article>
<p>Lorem ipsum get sum dim sum</p>

<blockquote>...Why do I suddenly crave chinese food?</blockquote>

<p>Lorem ipsum get sum dim sum is calling you</p>
</article>

Trajan Pro is an all uppercase font, and it's probably going to render much smaller than expected or desired here, as the blockquote inherits the font-size-adjust:. To be sure, there are a lot of unknowns that need to be considered with an "adjuster" property that is abstracted away from the actual property.

font-size-adjust: requires more planning, more math, more considerations for how it is to be implemented on a site.

Last comment

font-size-adjust: as a property name does not help with clarity IMO.
ex-ratio or lowercase-ratio more directly tell us what it's about.

Hi Scott @scottkellum

Font-x-size and font-cap-size along with the font-size property seem to imply these metrics can be controlled individually.

They could be controlled independently in theory — size, weight, and baseline shift are three parameters that come to mind that are useful to be independent for upper and lowercase.

My understanding of this means new font tech would need to be created, standardized and widely adopted to reliably implement this.

Well, on the browsers that have it, font-size-adjust: works to a degree.

If you go to this sample page using Firefox or current Safari, it's apparent that more is needed... font-size-adjust: is a baby-step start for what is ultimately needed.

To solve the issue of font-size-adjust inheriting independently from font-size with unwanted side effects, the scaling factor should be a descriptor in the @font-face rule.

PS: Nevermind, I just realized after hitting submit that I already mentioned #731 before.