I find the minified-font for the logo to be a little overkill, or is it just me?
Wouldn’t it be more efficient to just use a traced (= convert text to path in Inkscape) SVG as a logo?
If you do this, you can also manually adjust the kerning to make a really neat logo.
Making the text part of a logo an actual text also makes it automatically adjust its color when the user switches from a light mode to dark. I agree it’s not a worthwhile endeavor for every website, but I think it may be.
At this point I’d drop woff because the proportion of browsers that do support woff but don’t support woff2 is negligible, and ttf covers them anyway just with more bytes.
My preference would be for every webpage to use the user agent’s default font (and size!) Then I can pick whatever font I like in the settings, and have a consistent readable font everywhere. It’s not like my text editor is picking a different font for every file I open based on what the author of the file decided – why should text on the web be different?
Fonts are an aesthetic choice, along with things like layout and colors. Web pages are, like it or not, a visual medium. You might as well ask for every magazine in the world to publish in Times Roman 12pt.
Safari has a “Reader mode” that does what you’re asking for: it strips all styles and displays just the text and images in a user-selected font and bg color. Other browsers may have similar features.
By making sure the “layout still works” I thought he meant making sure it doesn’t break, not making sure it looks good. To me a well designed site should not break if a user picks a weird font, but I’m sure others would disagree.
It’s not just about aesthetically appealing, but about working well. Having sensible line lengths. Preserving grouping and alignment of related items. Ensuring that emphasized text stands out, but not so much to be distracting. “Small print” that isn’t too small. Headings that show content hierarchy, but without comically large or tiny fonts at the extremes.
This problem is tractable for relatively plain blog text, and browsers have “Reader” modes for that. But when the page is more information-dense and makes use of more sophisticated layouts (tables, figures, GUIs), it’s getting pretty hard to express it well without being able to rely on any typography.
Those things can be handled by HTML tags like <em>, <small>, <h1>, <table>, and <figure>, and if it doesn’t look sensible for a user’s default font that’s not your problem. Web app GUIs would require extra care to stay font-agnostic, especially because the frameworks used for web app GUIs don’t have this as a goal.
We’re talking about different things. To display information in a useful way it’s not sufficient to mark it up. If it’s not styled well, it’s going to be a chaotic word salad (text wrapping all over the place, weirdly narrow columns, low information density, unclear information hierarchy).
These problems aren’t technical with frameworks, but in human-computer interaction. When people are trained to expect a toolbar to be in one line, but your font choice makes it not fit in one line, then there are plenty of technically-possible alternatives, but they’re all poor: scrolling, hiding, removal of whitespace, truncation of labels are all obviously problematic. Wrapping will make the toolbar take multiple lines, taking precious vertical space, and move controls around, changing their visual grouping and logical order. In the end you need to have an algorithm for a skilled UI designer that will redesign UI to your style preferences. Maybe we’ll get there with A.I. that replaces UI designers, but the ability of styling semantic markup has peaked in Opera 7 with user styles and Opera Mini.
We’re talking about different things. To display information in a useful way it’s not sufficient to mark it up. If it’s not styled well, it’s going to be a chaotic word salad (text wrapping all over the place, weirdly narrow columns, low information density, unclear information hierarchy).
But that styling can be handled by the brower and the reader, so the author shouldn’t have to worry.
These problems aren’t technical with frameworks, but in human-computer interaction. When people are trained to expect a toolbar to be in one line, but your font choice makes it not fit in one line, then there are plenty of technically-possible alternatives, but they’re all poor: scrolling, hiding, removal of whitespace, truncation of labels are all obviously problematic. Wrapping will make the toolbar take multiple lines, taking precious vertical space, and move controls around, changing their visual grouping and logical order. In the end you need to have an algorithm for a skilled UI designer that will redesign UI to your style preferences. Maybe we’ll get there with A.I. that replaces UI designers, but the ability of styling semantic markup has peaked in Opera 7 with user styles and Opera Mini.
But resizing a window can have the same effect on a toolbar, and that is facilitated by frameworks and handled by web designers, at least to the satisfaction of some. If you can write a site that doesn’t depend on a particular window size it should be just as easy to write one that doesn’t depend on the font.
Reading code is a very different experience from reading prose. Text editors are intended to display code with fixed width fonts. Whereas bold and italic are essential for prose (in Latin character sets anyway), they are fairly rare for rendering code. There are other ways that variable width fonts used for prose are less interchangeable, too. Here are some properties that vary from family to another:
glyph size and legibility at the same nominal font-size
apparent line height at the same nominal font-size and line-height
line length at the same nominal font-size, container width, and text content
availability and behavior of font weights and variants
if and when the browser will apply faux bold to make up for lack of a specified weight
There was a brief moment when the cool kids were into brutalism (seemingly more in reference to brutality than to the architectural béton brut) that a regression to a pre-custom-font web seemed almost possible. Fortunately, it did not last long.
I suppose a counterargument is that browser reader views and feed readers tend to do a decent job of rendering text according to the user’s preference. However, they only work for text-heavy pages.
I find the minified-font for the logo to be a little overkill, or is it just me?
Wouldn’t it be more efficient to just use a traced (= convert text to path in Inkscape) SVG as a logo? If you do this, you can also manually adjust the kerning to make a really neat logo.
Having it be properly textual is kinda necessary for non-graphical users, although I guess that’s what the
altattribute is for.Making the text part of a logo an actual text also makes it automatically adjust its color when the user switches from a light mode to dark. I agree it’s not a worthwhile endeavor for every website, but I think it may be.
You can get that with SVG too, using
fill="currentColor".I didn’t actually think about that, but that sounds like a good option to me! Maybe I’ll explore that at some point in the future.
At this point I’d drop woff because the proportion of browsers that do support woff but don’t support woff2 is negligible, and ttf covers them anyway just with more bytes.
I’m a fan of this tool for compressing image formats: https://squoosh.app/
It’s also worth using modern compression algorithms, like brotli for static assets.
My preference would be for every webpage to use the user agent’s default font (and size!) Then I can pick whatever font I like in the settings, and have a consistent readable font everywhere. It’s not like my text editor is picking a different font for every file I open based on what the author of the file decided – why should text on the web be different?
Fonts are an aesthetic choice, along with things like layout and colors. Web pages are, like it or not, a visual medium. You might as well ask for every magazine in the world to publish in Times Roman 12pt.
Safari has a “Reader mode” that does what you’re asking for: it strips all styles and displays just the text and images in a user-selected font and bg color. Other browsers may have similar features.
Most text editors do, if you’re not a programmer. And I’m not gonna check if my site’s layout still works if you choose a weird font.
You shouldn’t have to if the site is well designed.
Designing a site to look good with any font imaginable is actually extremely difficult. Text layout is complicated.
By making sure the “layout still works” I thought he meant making sure it doesn’t break, not making sure it looks good. To me a well designed site should not break if a user picks a weird font, but I’m sure others would disagree.
It’s not just about aesthetically appealing, but about working well. Having sensible line lengths. Preserving grouping and alignment of related items. Ensuring that emphasized text stands out, but not so much to be distracting. “Small print” that isn’t too small. Headings that show content hierarchy, but without comically large or tiny fonts at the extremes.
This problem is tractable for relatively plain blog text, and browsers have “Reader” modes for that. But when the page is more information-dense and makes use of more sophisticated layouts (tables, figures, GUIs), it’s getting pretty hard to express it well without being able to rely on any typography.
Those things can be handled by HTML tags like <em>, <small>, <h1>, <table>, and <figure>, and if it doesn’t look sensible for a user’s default font that’s not your problem. Web app GUIs would require extra care to stay font-agnostic, especially because the frameworks used for web app GUIs don’t have this as a goal.
We’re talking about different things. To display information in a useful way it’s not sufficient to mark it up. If it’s not styled well, it’s going to be a chaotic word salad (text wrapping all over the place, weirdly narrow columns, low information density, unclear information hierarchy).
These problems aren’t technical with frameworks, but in human-computer interaction. When people are trained to expect a toolbar to be in one line, but your font choice makes it not fit in one line, then there are plenty of technically-possible alternatives, but they’re all poor: scrolling, hiding, removal of whitespace, truncation of labels are all obviously problematic. Wrapping will make the toolbar take multiple lines, taking precious vertical space, and move controls around, changing their visual grouping and logical order. In the end you need to have an algorithm for a skilled UI designer that will redesign UI to your style preferences. Maybe we’ll get there with A.I. that replaces UI designers, but the ability of styling semantic markup has peaked in Opera 7 with user styles and Opera Mini.
But that styling can be handled by the brower and the reader, so the author shouldn’t have to worry.
But resizing a window can have the same effect on a toolbar, and that is facilitated by frameworks and handled by web designers, at least to the satisfaction of some. If you can write a site that doesn’t depend on a particular window size it should be just as easy to write one that doesn’t depend on the font.
Reading code is a very different experience from reading prose. Text editors are intended to display code with fixed width fonts. Whereas bold and italic are essential for prose (in Latin character sets anyway), they are fairly rare for rendering code. There are other ways that variable width fonts used for prose are less interchangeable, too. Here are some properties that vary from family to another:
font-sizefont-sizeandline-heightfont-size, container width, and text contentThere was a brief moment when the cool kids were into brutalism (seemingly more in reference to brutality than to the architectural béton brut) that a regression to a pre-custom-font web seemed almost possible. Fortunately, it did not last long.
I suppose a counterargument is that browser reader views and feed readers tend to do a decent job of rendering text according to the user’s preference. However, they only work for text-heavy pages.