- From: Myndex via GitHub <sysbot+gh@w3.org>
- Date: Mon, 06 May 2024 04:46:55 +0000
- To: public-css-archive@w3.org
> _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