1. Don’t use web fonts.
2. There is no step 2
They just slow the web down and often make things less legible in the name of style.
How to avoid layout shifts caused by web fonts
101–110 of 126 posts
Re: How to avoid layout shifts caused by web fonts
#102Just use system fonts. Except on android, it's only roboto
And do use verdana, it's the most readable font. Admit it, you like it here
Re: How to avoid layout shifts caused by web fonts
#103If OS makers reached some kind of agreement to incorporate the most used 20 web fonts in their OS, 99% of this madness would be gone.
And use the same 120 fonts in our website? What are we, plebs? Plz download this 45mb font that we made this morning
Re: How to avoid layout shifts caused by web fonts
#104Earlier quoted context omitted.
But that's not what was being compared. How would electron apps render a "sans-serif" font?
What is being compared? Because to me it read like a question of choosing 'sans-serif' over 'ui-system-font-sans' or whatever in your CSS. Nothing more than that.
"System font stack" — which I took to mean the longish list of commonly known default fonts for a bunch of OSes brought up earlier in the thread — with a CSS value of "sans-serif".
There was no mention of direct use of Arial, Times New Roman or Courier that I could see, so I don't see why bring it up.
Re: How to avoid layout shifts caused by web fonts
#105Earlier quoted context omitted.
I was going to suggest that too. Separate metrics files have already been done too (both with TeX in TFM files and Adobe/PostScript fonts in AFM/PFM files), so you wouldn't even have to invent a new file format. Or you could simply use a regular font with no glyph curve data. I am a bit disappointed this is not covered in the original post, and that no effort is being put in W3C to make that easy and viable.
> I am a bit disappointed this is not covered in the original post, and that no effort is being put in W3C to make that easy and viable. Yes. What would be interesting is if you could use an a-priori available font (system font), and combine it with a website-provided font metrics file. That way, you can render visible text immediately, and then later render the correct font without layout change.
Yeah, but strictly as a solution to shifting layout, having metrics asap and actual text display later — when the glyph data is downloaded — is the most obvious solution.
Rendering a similar system font (by metrics comparison, ideally) in its place is indeed a great improvement on this, but mostly for the render-as-soon-as-possible problem.
I'd treat it as a separate problem simply because it can be on the user agent to decide to do it and how, and even without it, a bunch of web apps would start benefitting right away (those which have most of their actual text off screen but which might block rendering other parts of the page).
Re: How to avoid layout shifts caused by web fonts
#106Earlier quoted context omitted.
Branding is bit subtler than that — you’re not going to really say anything about Target’s consistent styling, versus Walmart’s fairly austere aesthetic, but you definitely get a different “feel” from each, before looking at their actual contents/stock. I don’t know whether fonts are really that important to the total equation, but “not terrible enough to walk out the door” is generally a very low bar to meet when de…
I’m not sure I understand the point about enterprise apps, because that can go both ways. Custom company application tend to be the worst, because they apply all the company branding guidelines, rather than just applying to system defaults.
I’m not making the case that one being better than the other, or really trying to say anything about custom vs enterprise.
My main point is simply that there’s a significant gap between “it can be used” and “it can be used well” — and a designer’s primary job is to bridge that gap (generally the engineer in us takes us to “it can be used”). That (some? many? majority?) designers aren’t competent is a separate concern… but their abstract goals are fairly obvious and intuitive if difficult to specify concretely
And we understand this intuitively, because there are many apps in our section of the universe that fall under it can be used — back-office apps, enterprise apps, etc a constant offender (not say good ones don’t exist, or bad custom apps don’t exist, or bad designers/designs don’t exist… etc — but we’ve all probably encountered a good few that are astoundingly unpleasant to use)
Re: How to avoid layout shifts caused by web fonts
#107Earlier quoted context omitted.
cool. why don't you kindly ask them to fix the fonts by a bug request instead of everyone just assuming the stuff is shit
How productive do you think it would be to open a bug report with Microsoft telling them that Segoe UI/Arial/etc. are hideous? Do you think they will change them for me and/or license some good looking fonts to bundle with Windows? Complaining and not using them is the only real option.
do you have a specific problems with fonts in say gnome or kde team? they would be more responsive for sure.
besides, i refuse to accept that the billions microsoft and apple in particular spent on truetype/cleartype fonts or whatever the tech is, is so poor that you are forced to use something else. i... i mean how can that be.... do you have some proof of this?
>Complaining and not using them is the only real option.
so microsoft and apple will be in your opinion forever content with shipping "shitty fonts" as "defaults" which run on billions of devices, android comes with fonts that run on many billion devices and they ALL are using shitty defaults and these multi trillion dollar companies do not know better than your average hacker news reader. nice. i am in good company lads.
Re: How to avoid layout shifts caused by web fonts
#108Earlier quoted context omitted.
Why not just `body {font-family: sans-serif}`? Like, you don't have to explicitly enumerate all sans-serif system fonts ever. The browser will handle it.
Sometimes you care a lot about the design of the website and that everything looks 100% OK in all browsers and screen-sizes. For example, think web agency landing pages, where you're supposed to sell your service to potential customers. In those cases, using whatever font is usually not good enough, because many of them have different sizes (both length-wise, height-wise and line-height-wise), so if a user gets a dif…
If you care that much you need to bundle the font with your site.
Re: How to avoid layout shifts caused by web fonts
#109Earlier quoted context omitted.
i have tried to ask people a simple question. "why do you think you know fonts better than microsoft or apple?" not to even talk about linux for a moment here. do these multi trillion dollar companies making operating systems do a shit job at fonts that each and every website developer needs to use google fonts that increase dependency on third parties than using system default fonts?
Not particularly a fan of custom fonts, but fonts are not one size fits all. Apple or Microsoft default fonts are designed for the general use case, and other fonts might be more suited in a different context. Whether that's worth the cost, that's a different question.
come on. i am not expecting to visit an art gallery when i browse the current website or your local news portal or a blog or youtube. do you really think each and every website "needs" to individually tailor fonts to their "exact millimeter position" or otherwise the result will be utter garbage?
>and other fonts might be more suited in a different context
that is why "general use case" is my point. can you point me a specific example of where my current default "noto sans 10 pt" in kde neon is NOT suited for a specific use case? i want to see that unless i use a developer decided font, i would be totally off base, i would miss the plot, i would read garbage, etc etc.
Re: How to avoid layout shifts caused by web fonts
#110Earlier quoted context omitted.
> How to avoid layout shifts caused by images. And it’s funny how the state of the art way to address these issues is usually some absurd hack. Like in the case of images, setting the height to 0 and using padding to achieve a stable height: https://nikitahl.com/css-aspect-ratio .
The aspect ratio hack was replaced by the aspect-ratio CSS property: https://web.dev/aspect-ratio/ Which is supported in all modern browsers: https://developer.mozilla.org/en-US/docs/Web/CSS/aspect-rati... The state of the art for CSS these days is not that hacky.
Cool I didn't know this. Thank you.