Re: Thoughts on Font-x-size property for CSS

Here’s the quick response:

The reason it needs to be a CSS property is that is what is needed to make the use of x-height sizing into a practical part of the WCAG 3 standard (and potentiall a WCAG 2.3). For standards & guidelines, it is not just about determining a best practice, but also specifying a common and reasonable path to conformance, or else no one will be conforming. 


DETAILED ANSWER:

No Polyfill
It is unreasonable for a guideline to require a JS polyfill to fix something that needs to be a CSS basic property. And what about sites that are not using JS? There are legitimate reasons to NOT use JS, including accessibility reasons. Also a polyfill that does some form of optical size estimation is not a “simple polyfill”.

I made an addendum earlier to my CSS post that more clearly states that font-x-size: is intended as a replacement for font-size:


The goal is a practical STANDARD, not a patchwork of polyfills.

This is not an internal issue of a single organization to solve an internal problem, this is about an international standard that affects billions of people and hundreds of millions of sites. “We could just…” is a great go-get-em means for some individual company. But that is far from what we are talking about here.

No Lookup Table
Also, no, it is far beyond any practical means to create a table of x-height ratios. Here are examples why:

“What Font Is” has a catalogue of 550,000+ fonts
https://www.myfonts.com <https://www.myfonts.com/> hosts 130,000 fonts.
Fonts.com <http://fonts.com/> hosts 36,488 Families, and there are countless more.

Also, the PANOSE font characterization system was an attempt to have a central registry. It is of no real benefit to anyone, and pretty much a failure. The nature of the font market does not support this kind of thing.

But also, that’s not how CSS works, and is a misunderstanding of the nature of the structure of web content, and this is in no way an easier path to standardization when it would require the same kind of codification and browser support or the use of excessive polyfills and the resultant code bloat leading to non-adoption and non conformance, i.e. wrong direction down a dark alley.

Why CSS
A standard CSS property BYPASSES ALL OF THAT.  

And right now, the next CSS working draft is getting close to a recommendation, which is why this is a pressing issue.


Andy


> On Oct 7, 2021, at 4:10 AM, Christopher Loiselle <chris.loiselle@oracle.com> wrote:
> 
> Hi Sam,
> 
> Thank you for your thoughts and detailed response. We will review this together as a group and discuss. I appreciate all your work on these topics.
> 
> Thank you,
> Chris 
>  
> From: Sam Waller <sdw32@cam.ac.uk <mailto:sdw32@cam.ac.uk>> 
> Sent: Thursday, October 7, 2021 4:45 AM
> To: public-low-vision-a11y-tf@w3.org <mailto:public-low-vision-a11y-tf@w3.org>
> Subject: [External] : Thoughts on Font-x-size property for CSS
>  
> Dear all
>  
> I noted Andy's discussion thread on this topic with interest.
>  
> https://github.com/w3c/low-vision-a11y-tf/discussions/118 <https://urldefense.com/v3/__https:/github.com/w3c/low-vision-a11y-tf/discussions/118__;!!ACWV5N9M2RV99hQ!Yj8V8qTvpqh9xrGdBAlpIzMTot34WL-zzfKgKlca1t0ZBToYBwkD4no0ufXA8d3jtHI$>
>  
> I tried to comment on this thread in Github, but at the moment it seems I'm not able to, and I'm trying to resolve this as a separate issue. 
>  
> In the meantime though, in preparation for discussing this topic later today, I had the following thoughts:
>  
> I absolutely agree that the guidance needs to specify a minimum x-height, and also that we need to be able to offer guidance on font-weight in an absolute sense (in terms of the stroke thickness of the letters), rather than a relative sense, like font-weight: 400, which means something different for different fonts.
> I wondered if this could be solvable via an API, rather than attempting to change the CSS spec. I'm not a JavaScript programmer, but I believe something like the below procedure ought to be somewhat trivial for an experienced JavaScript programmer to implement. This would take an input of the font-name, and then return the ratio of x-height to font-size, by doing something a bit like the following:
> create an HTML canvas of 100 x 100px with a white background
> render the lowercase letter x onto the canvas, in pure black, with the given font-name and setting the font-size to 100px;
> export the entire canvas to PNG
> trim the PNG to eliminate the white pixels
> report the height of the image that results as a proportion of the original HTML canvas height.
> A similar procedure could perhaps pick a different letter to try and get the stroke width of the letters as a ratio of the font-size, although this may need some further thought.
> Using this API, I would have thought it would be possible to automatically generate a table of pretty much every font name that currently exists, and the ratio of x-height to font-size. (Assuming any font licensing issues can be resolved)
> It should then be possible to dynamically query this lookup table, or indeed use the above API on the fly in order to automatically assess webpages to determine if the x-height of the fonts is sufficient, given the font-name and the font-size.
> It should also be possible to create a tool that takes the font-name as an input, and returns the minimum font-size, based on the minimum x-height in our guidance, and the known ratio of x-height to font-size from the API, or indeed the lookup table.
> Doing something similar for font-weight would be ideal, and would need some further thought.
>  
> I would have thought the above could be ready to implement in a matter of days, whereas I would have thought that changing the CSS specification would take years, and then some more years before all browsers supported it, and even then backwards compatibility would still be a pain!
>  
> I will look forward to further discussions on this topic, many thanks.
>  
> Best wishes
>  
> Sam Waller
> University of Cambridge, Engineering Design Centre
> 01223 332826
>