And these overrides can be applied to local fonts as well (generally used to ensure the metrics of the local fallback font matches the yet-to-be-downloaded web font, preventing a layout shift when the web font is swapped in)
ascent-override - https://developer.mozilla.org/en-US/docs/Web/CSS/@font-face/...
descent-override - https://developer.mozilla.org/en-US/docs/Web/CSS/@font-face/...
line-gap-override - https://developer.mozilla.org/en-US/docs/Web/CSS/@font-face/...
size-adjust - https://developer.mozilla.org/en-US/docs/Web/CSS/@font-face/...
div.content {
width:400px;
voice-family: "\"}\"";
voice-family:inherit;
width:300px;
}
https://meyerweb.com/eric/tools/css/reset/
Version 1 was published in 2008:
/* http://meyerweb.com/eric/tools/css/reset/ */
/* v1.0 | 20080212 */
html, body, div, span, applet, object, iframe,
h1, h2, h3, h4, h5, h6, p, blockquote, pre,
a, abbr, acronym, address, big, cite, code,
del, dfn, em, font, img, ins, kbd, q, s, samp,
small, strike, strong, sub, sup, tt, var,
b, u, i, center,
dl, dt, dd, ol, ul, li,
fieldset, form, label, legend,
table, caption, tbody, tfoot, thead, tr, th, td {
margin: 0;
padding: 0;
border: 0;
outline: 0;
font-size: 100%;
vertical-align: baseline;
background: transparent;
}
body {
line-height: 1;
}
ol, ul {
list-style: none;
}
blockquote, q {
quotes: none;
}
blockquote:before, blockquote:after,
q:before, q:after {
content: '';
content: none;
}
/* remember to define focus styles! */
:focus {
outline: 0;
}
/* remember to highlight inserts somehow! */
ins {
text-decoration: none;
}
del {
text-decoration: line-through;
}
/* tables still need 'cellspacing="0"' in the markup */
table {
border-collapse: collapse;
border-spacing: 0;
}So, if you need flag icons for any reason (e.g. phone number country code input), you'd have to use a different emoji font.
https://techcommunity.microsoft.com/t5/microsoft-teams-publi...
But then again, I also loved the Android's old blob emojis[0]. Some specific ones were weird but mostly I really liked the amount of personality and movement they were able to express. But as far as I've been able to tell, most people seemed to hate them, for whatever reason.
macOS doesn't even render to its own high pixel density displays correctly, owing to the (in my opinion) very naïve algorithm used. If you select any resolution that's not a perfect factor of the display being rendered to, then there is blurriness[1]. MacOS renders to a viewport that is 2× the resolution of the 'looks like' setting, and then scales it down to the actual monitor resolution. Clearly, at any non-integer multiple resolution, there is blurring.
This is problematic enough that it defeats Apple's 'good font rendering'. I see shimmering and ringing artifacts around regions of high contrast (i.e. essentially all text) with such a non-native setup. I am forced to use the integer factor resolution, which makes things much too big. Of course, I can scale my browser and VS Code, but besides that the rest of the OS is comically large. Needless to say this also comes with the large performance impact of always rendering to a viewport four times the resolution of a given display. It is also non-intuitive to program against, especially using APIs like GLUT, SDL, etc.
Windows is the only OS that actually does high pixel density rendering correctly for programs that support it[2]. Windows works with the given monitor resolution, and scales UI elements according to the percentage value set (100% is 96 DPI). This is a lot more involved to program for, but when done right, it works exceptionally well. Everything that's not a raster image is always pixel-perfect. If it's not (and people have complained about this[3]), then there's a system setting/registry patch to make it so[4].
Windows also handles moving program windows between displays set to different DPIs quite seamlessly. The only issue I see is when a new display with a different scaling setting is set as the primary (and only) display, and then Windows Explorer scales things weirdly—which is fixed by restarting Explorer.
On Linux... Forget it. On Xorg there are a million environment and per-app-specific configurations to set (just see how long the HiDPI article[5] in the Arch Linux wiki is). On Wayland, things are better, but not yet for me, since I use an NVIDIA graphics card, KDE Plasma, and Chrome, which is the worst possible combination for Wayland. It's not mature enough for this setup—the Windows-esque rendering (they call it 'fractional scaling') was only merged in slightly more than a year ago[6], and Plasma 5, my DE of choice, still doesn't quite use it yet.
[1]:
[2]: https://building.enlyze.com/posts/writing-win32-apps-like-it...
[3]: https://news.ycombinator.com/item?id=38444967
[4]: https://serverfault.com/questions/570785/how-can-i-make-micr...
[5]: https://wiki.archlinux.org/title/HiDPI
[6]: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/m...
This explains better than I can
If someone insists that an app on the Mac should look the same as on Windows they’re an idiot. If they say an app on the Mac should look the same as a web page on Windows or Linux they’re a malicious idiot.
Huh? Different from what? It's described as exactly the same thing as the ascent, but down. And why does the author specify web fonts? This sounds like it applies to fonts in general.
Edit: I think the author is just trying to say the descent varies across fonts, even measured in em. I think "web fonts" and "glyphs can have tails" are just red herrings.
fodder for a horror movie if I've ever heard it.Did he ever write about this? I can't see anything about it in his list of articles.