（评论）

（评论）
(comments)

原始链接: https://news.ycombinator.com/item?id=41502721

在 HTML 的早期版本（特别是 4.01 版本）中，有一个提议的功能称为“对齐属性”，允许数字数据自动对齐特定字符。然而，此功能从未在浏览器中完全实现，后来被认为已过时。相反，HTML 中的样式已转向使用 CSS。目前，某些 OpenType 字体具有替代字形，例如 Georgia 字体，它会根据周围的上下文（数字与字母）在不同变体之间切换。要利用这些功能，所使用的字体必须包含数字字形的正确变体。然而，由于不同的编码方法以及不同字体和应用程序之间不一致的命名约定，实现字体功能可能具有挑战性。因此，在如何显示某些字体特征方面可能会出现冲突，从而使开发人员更难为他们的项目选择合适的字体。使用自定义或第三方字体可能会降低网站速度，尤其是在移动设备上，从而影响搜索引擎优化 (SEO)。更快的加载速度对于改进 SEO 至关重要，添加额外的字体会显着增加页面加载时间，可能会损害整体性能和排名位置。为了实现最佳加载时间，建议尽量减少第三方字体的数量，并尽可能坚持使用系统字体。选择轻量级、快速加载的自定义字体可以帮助保持较高的 Core Web Vital 分数，而不会对 SEO 产生负面影响。

> Since such numerals line up when typed on multiple lines, they're useful in, well, tabular data: tables, bills, reports, you name it.

Or things like showing a clock, countdown, whatever. A time that "jumps around" on the screen from one second to the next annoys the hell out of me...

I like tabular numerals. But you really need a small set of other glyphs to be tabular to really make them work. In particular, you need the plus and minus signs to be the same width, so that in a table like:

  gold +1.2%
  oil  -6.4%
  corn +5.2%

everything lines up and looks nice. At the moment, with CSS, there's no way to make that happen, and in normal typefaces the hyphen-minus is too narrow. You can replace the minus signs with a wider dash, but that is semantically wrong and also a pain in the arse.

It occurs to me that contextual alternates could make this Just Work. I haven't used any typefaces expensive enough to do that though!

> the hyphen-minus is too narrow. You can replace the minus signs with a wider dash, but that is semantically wrong and also a pain in the arse.

In this case, an alternative to "-", U+002D HYPHEN-MINUS, is "−", U+2212 MINUS SIGN. On Linux, I considered mapping the keypad substract key to it, but instead I configured a xcompose alias.

  gold +1.2%
  oil  −6.4%
  corn +5.2%

It vexes me that almost no one uses the real minus sign. But you also can't blame them since it's never been made readily-available. So you really have to be pedantic and spend time going to get it if you want to use it.

Most people aren't even aware there's a "real" (or rather, fake) minus sign. I didn't know until reading this thread. The hyphen is right next to the +/= key, so it's not unreasonable at all to think the _/- key is minus.

Mac OS has option+- for en dash and option+shift+- for em dash. I used to add similar bindings on Windows via AutoHotkey (which is an amazing app all around...)

There's also option+space for and other goodies. I recently added option+x for "checkmark x" and option+v for "checkmark v" since I like dropping those around more often than I should...

https://www.w3.org/TR/html401/struct/tables.html#h-11.3.2

HTML 4 was still in this weird in-between time where there were styling attributes in HTML coexisting with the upcoming CSS. Afair no browser ever implemented character alignment and in Google’s HTML it is only written up as obsolete:

https://html.spec.whatwg.org/multipage/obsolete.html#dom-tab...

Styling in general is of course a CSS thing – but thinking about it arranging alignment in multiple interdependent elements is a problem which not just need a property but a layout algorithm which browsers then need to implement. So we still don’t have nice things.

> It occurs to me that contextual alternates could make this Just Work.

The replacement mechanism in OpenType fonts is surprisingly useful. I remember Apple’s San Francisco font switches between different variants of the colon if it follows text characters ("my proposal: nuke it from the orbit") or if it exists between numbers as in a time ("23:52"); in the latter it is more centered.

Back in the days of HTML 4.01 there was the idea of an align attribute where possible numerical data could auto-align on a specified character:

€ 1.20

I hear you. Back when I was in Investment Banking, I was guilty of replacing hyphens with en dashes in all sorts of labels to make them line up properly in a table... It wasn't perfect, but it was a decent improvement

Generally, numbers were right-aligned in cells, so the % at the end was consistent (when present) and the plus/minus before the numbers didn't make a difference because of the alignment. But labels on the left like in some P&L or Cash Flow statement were always annoying

I suppose one way to make it work in CSS would be to split the numbers on the decimal points, and align the parts as necessary. Though there's no way to get around the

/ soup, unfortunately.

The easiest solution is to make a custom font with all the glyphs you want to be tabularized given the same advance width. Then you aren't subject to the vagaries of getting advanced font rendering to work.

>you need the plus and minus signs to be the same width

I've never thought about it, but that is somewhat annoying that the math symbols aren't a consistent width with each other.

Also U+2012 FIGURE DASH (for things like phone numbers), and probably U+2212 MINUS SIGN (aligned with plus). Everyone usually defaults to hyphen-minus though, and all bets are off.

Tabular numerals are very useful in certain cases, but I find even more useful the old-style numerals.

By default, I always use old-style numerals, because they are much easier to read, especially for big numbers, for the same reason why the lowercase letters are easier to read, by having ascenders and descenders that break the uniformity of the characters.

I use lining numerals only in the same places where I would use uppercase letters, e.g. in titles or when a sentence begins with a number.

>I find even more useful the old-style numerals

A font of antiquated faſhion doth boaſt moſt excellent and ſubſtantious qualities, yet prithee, what of olde ſtyle figures doſt thou deem hath beneﬁt that I, in mine own diſcretion, might chooſeth?

Set thy eyes on this excellent Font, for Inſtance: https://en.m.wikipedia.org/wiki/Georgia_(typeface)#/media/Fi...

As can be moſt clearly ſeen, the Numerals are not of equale Height, but poſſeſs Deſcendants, like the 4, and Aſcendants, like the 6.

Shouldſt thou deſire to embelliſh thy Layout with ſuch a Rendition of Numerals, thou canst: https://developer.mozilla.org/en-US/docs/Web/CSS/font-varian...

This Feature requireth though that the Font ſo employed containéd the proper Variants of the numeral Glyphs. Many a diſtinguished Font do.

(Pray note that the -th Ending of Verbs is for Singular Third Perſon Form, not to be uſed with "thou". I do, thou dost, he doth.)

Caveat: Google Fonts, and by extension Fontsource which mostly just mirrors Googles files, strips out nearly all of the advanced OpenType features to reduce the filesize. It's worth checking the upstream version of your font to see which features it actually offers.

e.g. Wakamai Fondue lists 11 features for Googles version of Inter (some essential ones plus fractions, tabular numbers, numerators, denominators and contextual alts), while the full fat version of Inter has a whopping 44 features (too many to list, see https://rsms.me/inter/).

it's the year of the lord 2024 and OSes still don't ship with a common set of open license fonts with most of unicode like nerdfonts. shameful.

I wish all the effort the big four wasted fighting for emoji supremacy would have been used to normalize a decent set of full unicode fonts once and for all.

Wow, is Inter ever a beautiful typeface. A rare find when there seemed to be a glut of corporate NIH typefaces for a while.

macOS used to ship with a beautiful Hebrew typeface that was like the open-source font Shofar, but it seems to have been removed. I do not see similar Hebrew letters in one of the remaining typefaces. I imagine that it is not easy to give a typeface a consistent feel, in all Latin and non-Latin character sets, to the fluent readers of those languages.

Inter quickly became my go-to sans serif font for the web. In A/B tests it somehow always looks better than anything, frequently by wide margins—which is saying something when you’re basically running through a dozen variations on Helvetica.

The number of fonts that include even two good alphabets is pretty low. I have run into needing english and greek or cyrillic in the same document. I know of like three good fonts that have a good english and a good greek. My eye isn't as practiced at looking at cyrillic fonts but it seems even rarer for that combination.

Which honestly makes sense and there may not be a solution for. Different alphabets and writing systems have their own typographical histories and conventions. It's reasonable that there is a very limited design space where you're adhering to the conventions of two separate systems as well as maintaining interior consistency.

Can't expect the big four to use their immeasurable wealth for the common good, now can we?

If anyone, then distro creators and maintainers will have to make that step. Google surely enjoys getting so much information due to hapless users loading Googlefonts on websites.

In some important areas France has better laws than other EU countries. Another example I believe was about avoiding wasting food on the supply chain of food to supermarkets and what happens with food afterwards.

Noto doesn't ship with OS, and users need multiple fonts for different use cases.

Grandparent comment is saying that Microsoft, Google, Apple could settle on a common set of open licence fonts and bundle them with the OS (and Linux distros / other OSS OSes could also do the same). Then web design & dev could rely on those fonts without having to locally serve them, or embed with Google fonts, etc. Noto could indeed be one of the bundled fonts in this alternate reality.

But no real incentive for any of those big players to do so, and disincentive for Google who gain surveillance data from font embeds as noted elsewhere in thread.

first of, currently it is impossible to cover all of unicode because, surprise surprise, we still have page table issues!

the same char in zh, tw, jp, kr might use the same unicode id but have different glyphs.

secondly, yes, but even google fonts strip most things from noto it serves because they want the fine grain data of each site/user is using wink wink.

Proprietary OS problem. Linux distributions package and distribute all the fonts they're legally allowed to ship. Every font I ever cared to use can be found in the repositories. And they don't strip out features either. I get to customize everything about Fira Code.

> Every font I ever cared to use can be found in the repositories.

If you have to download/install them separately then it means it doesn't ship with it. The fact that you can install it from the distro repositories means nothing to a third party website that can't assume you have done so.

Websites can't really assume anything that's not a web standard. If this is important to them, they should be lobbying the web standards bodies to come up with a list of fonts that browsers are required to make available. Then the browsers will pull them in as dependencies when they're installed.

The Linux distributions did their jobs with excellence. The fonts are all there and installing them is a oneliner. The web folks made their own OS though so if anyone is to be blamed it's whoever is in charge of that OS called the web platform.

Who's in charge of the web as a platform these days? Google. Who is no doubt profiting from the Google Fonts thing.

correct. that's why I mention the nerdfonts as the holy grail.

but without the big OSes agreeing on a new unicode, today it's technically impossible to have a single unicode font (see how noto ships 200 variants on linux, all having some 500mb and only differing a few chars from one another. it's a monstrosity)

Sometimes they might also ship outdated versions, e.g. the last released version of Fira Sans is 4.301, but Google still only serves version 4.203. Plus technically Fira Sans has been superseded by Fira Go, which includes additional scripts, but Google doesn't offer that one at all.

Yeah, I'm waiting to see if BM condensed ever arrives. I am thinking it won't. I don't think it would take this long if they really intended to get v2 out the door. It's vaporware.

Would also love to see v2 finally get released, since I'm a big fan of Berkeley Mono and would like more weights and widths to make my Emacs look nicer.

From their update in february[1] this year it seems like it is basically complete but personal things got in the way and maybe they struggle to set up the systems for custom builds, ecommerce, etc. to ship it. People are constantly asking for the release, so I think it will eventually arrive, but good things often take longer than expected. :)

[1]: https://x.com/usgraphics/status/1762128387483824160

BM condensed, where does that land on the Bristol stool scale? Sorry I couldn't resist.

I am actually curious about this though, the Berkeley Mono font I found with a search does look quite nice. What's the deal with v2?

I've bought v1 and I'm quite happy with it as it is. It's just that I've been looking forward to the tweaks that'd been described for the last year and a half, like[0]:

"We threw away almost all of v1.00X, Berkeley Mono v2.000 improves substantially on legibility, fitting, and cohesiveness, especially for bold weights."

If I hadn't heard of v2 I wouldn't be missing it. But I have heard of it, goshdarnit, and now I want to see the new shininess!

[0]https://x.com/usgraphics/status/1629588764560625664

Not really related: to get VSCode to support comments, jsdocs, other syntax highlighting features using different fonts, you will probably have to use the extension vscode-custom-css from be5invis: https://github.com/be5invis/vscode-custom-css

Mine is:

  .mtki {
    font-family: 'IosevkaNFM-ExtraLightItalic', monospace !important;
    font-style: italic !important;
    color: #757575 !important;
  }

  .comment {
    font-family: 'IosevkaNFM-ExtraLightItalic', monospace !important;
    font-style: italic !important;
    color: #757575 !important;
  }

  .comment:not(.punctuation) {
    font-family: 'IosevkaNFM-ExtraLightItalic', monospace !important;
    font-style: italic !important;
    color: #757575 !important;
  }

Which looks like the last picture in this comment: https://github.com/microsoft/vscode/issues/36512#issuecommen...

Just be prepared to experiment a lot, VSCode's (Electron's?) font handling is buggy.

Why are font features so difficult to support correctly?

  Why are font features so difficult to support correctly?

Because the standards are mostly a result of slapping the name "OpenType" on existing behavior. There's maybe three or four ways to encode any given piece of information. The standards are a mess.

You can identify a font as italic in four different places with varying semantics. Off the top of my head, three different places to mark a font as bold (and this may not jive with the weight). Three different ways to specify vector glyphs (five if you include 'COLR' and SVG). Raster glyphs? Do you want PNG, JPEG, TIFF, or raw bytes? Should the raw data be bit or byte aligned?

The result of that complexity is that fonts often have all sorts of conflicting information. Depending on what behavior you're referring to specifically I'd be that the fonts themselves may be to blame. TrueType style glyphs specifically put a lot of burden for getting the hinting right on the font designer. CFF/CFF2 doesn't.

Noto went full Google. Noto Display was abandoned a few years ago. In their own words it's not intended to be what most folks would consider a display font so there's no good replacement. The metadata in last release is all kinds of fucked up.

Names are a hilarious shit show, what constitutes an appropriate name varies from font to font leaving app makers to come up with their own magic and leaving font selection a huge mess. Plus names can be encoded in any number of encodings. Apple still has MacRoman encoded strings in some of their fonts. Is Arial Black the black weight of Arial or a whole new font family?

What is going on with the wght (weight) axis? When I slide to the left of 400, the text condenses as it gets thinner. But to the right of 400, the text does not expand, it just gets thicker. So it would not appear to be a continuous variable, as the slider would suggest.

If you like typography, check out Butterick's Practical Typography: https://practicaltypography.com/ It's full of good, pragmatic advice on how to make printed and digital documents look wonderful.

I've bought two fonts from him and his font license is easily the most permissive of any paid professional font I've seen: no restrictions on the number of page views or anything, unlike most other pro fonts. Are his fonts open source? No. Are there good open source fonts? Of course. But are his fonts beautiful? You bet. I've got Valkyrie and Concourse. Concourse is particularly flexible when it comes to contextual alternatives and such.

Nice thanks! I'm happy to pay for a good font but the page view restrictions and all have always bothered me. Not a fan of the idea that they might end up extorting large sums out of you down the line if your site becomes popular or if you want to to build an app with the font to keep your branding consistent.

Fascinating that it's just now that someone got curious about this enough to write a post. I know if you looked for it you'd probably find this stuff but it is definitely scarce IMO. Thing is, not enough developers and designers that worked on this for many years bother to blog about it perhaps for reasonable reasons but still.

Also Recursive (https://www.recursive.design) which has the usual weight and slant axis, with cursive alternates which can be toggled explicitly or used automatically when the slant is strong enough, but also a monospace axis (which allows for semi-monospace) and a "casual" axis which changes the whole character of the font.

I'm a bit surprised as I thought this was common knowledge for web designers and developers.

Though to check the features or variable ranges of an OpenType file, you can use something like fontdrop.info.

Loading a font can cause multiple things including load time delay. For example, connecting to Google and downloading a Lato font is around 4-5 requests + js + CSS files + 500kb added download.

Processing the font itself also is at least 500ms to a second depending on the device type.

We keep the total requests under 25, which cannot be done after multiple 3rd party fonts are added.

Additionally, some fonts can introduce CLS (content layout shift) after the font is loaded. Especially H tags because they shift a lot. CLS = your SEO is dead.

For speed purposes, especially mobile, using a 3rd party font is SEO suicide.

The sites we build for our clients are below 1.2 second mobile and 0.2 second desktop load time which gives these sites an enormous SEO advantage. These load times are complete loads, not initial draws or TTFBs. (results are provided by Google page speed insights - https://pagespeed.web.dev/) These load times change when we use the client's own fonts or the ones they pick from Google fonts. We have this discussion almost every time we onboard a new client.

  Processing the font itself also is at least 500ms to a second
  depending on the device type.

I think that's off by quite a lot.

On my MacBook Pro I can dump one of the Helvetica Neue faces in one second with ttx (fonttools). If a python script can parse a font, create an XML representation, and write a pretty printed version of that to disk in a second then yea 500 ms seems really slow.

Hell, typst (rust) can render a PDF with two subsetted fonts (Apple Color Emoji + Cambria Math) in about 750 ms. I certainly hope Harfbuzz is at least that fast.

Google's crawl emulation is based on this:

Emulated Moto G Power with Lighthouse 12.2.0 - Slow 4G throttling.

With slow download and rendering it is probably more than 500ms in my opinion. Either way, I won't leave money on the table and sacrifice 1% better-looking fonts, even if it is for 10ms. Mobile load time is the #1 SEO signal these days and will stay #1 for a long time.

Right, but your claim was that just processing the font would take 500 ms. No idea what a Moto G Power is or how fast it is, but 500 ms for processing still seems like a pessimistic estimate.

I've no idea what sort of overhead Google adds to font downloads either, but assuming WOFF2 format the font itself should be well under 100k. Granted WOFF2 is fairly new (2018), but it's fairly well supported these days. I'd expect Google Fonts to support it as WOFF2 was Google's attempt at wringing out a bit more optimization out SFNT fonts.

Alright, sorry to make it sound like that. Either way, it adds overhead (local or Google) but CDN-loaded ones cause more issues. Google Fonts is the web's standard for non-system fonts and indeed it adds CSS, JS, additional requests, and the font itself, including wait times due to download and load. SEO is a competitive environment, even a single request, and ms counts. Small blogs might not care but if your website gets traffic, those little millisecond differences rank your posts differently.

Our pages are around 80kb in total (yes you are reading correctly, not 800kb but 80kb including images of the blog posts, including the WebP images, javascript, CSS, and the HTML file itself. Imagine doubling or quadrupling it just for a font. That would be insanity. 100kb font size is absurd if you want your mobile speed (#1 SEO factor today) to be better.

Core Web Vitals scores us 100% for everything. This drops to 80%~ when we use external fonts. We tried 100s of different metrics. The font is a major factor (again, doesn't matter local or Google). Added overhead is going to sink your ranks like a rock.

For anyone reading this, do not use Google fonts if you want your SEO to be better.

as a designer by education, this level of font control for web is delusional. and mostly a waste of time (both for the designers and the users receiving on unexpected screen ratios/resolutions/tech/era/etc and getting a worse experience if the designers hadn't wasted the time)

this brings me bad memories from the time websites were done by "desktop publishing" designers and html was crafted "pixel perfect" (with tables)

thankfully I can easily be a curmudgeon and just set all sites to use my favorite fixed width font and disable the designers choice with one checkbox on firefox.

（评论） (comments)

（评论）
(comments)