Re: [csswg-drafts] [css-fonts] Font Sizing for Readability (#6709)

> _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:

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

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


```

**_VERSUS_**

```CSS
/* 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:

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

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

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

And the HTML is:

```HTML

<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.

-- 
GitHub Notification of comment by Myndex
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6709#issuecomment-2095191689 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Monday, 6 May 2024 04:46:56 UTC