HTML + CSS for whitespacing & viewport width + SSI | Caddy's template
That combo is more than enough for almost all the websites out there, I've 3 different sites like that and they are blazingly fast, everything served from a $4 VPS (serving about 20k views per week).
I never released a production website with SSI before, but I found it when I was searching for a more bare-metal approach to make websites; then I found Caddy's template engine and it's been more than enough for what I need.
This is the way. It's great for templating with .html fragments, extremely easy to maintain and has almost no attack surface. I don't know what "Caddy's template" is but HTML/CSS + SSI for gluing the fragments together is what peak personal website performance looks like.
SSI is supported by "old battle tested" servers like Apache or Nginx, there's a "new guy on the block" that I find quite promissing: Caddy[0] however it doesn't support SSI, instead they have some built-in template engine that is a bit more powerful than old SSI but can achieve the same result.
I guess you mean because SSI is just a very limited mechanism as opposed to full blown Turing complete PHP or similar. But actually if the fragments/partials you include via SSI are user-posted content (comments) or syndicated content then of course SSI can't fence against <script> or other injections. In that case, you could use more sophisticated SGML mechanisms (other than SGML processing instructions as used by PHP or magic SGML comments as used by SSI) such as entity reference expansion that come with full type checking and context-dependent validity assessment for filtering all kind of injections (script elements, event handler attributes, image or link href injections or whatever). But you should at least use content-security-policy headers to block inline script.
You may not even need HTML. HTML is subject to different renderings on different browsers, confusing features that may not be supported on different browses, and may tempt you to use JavaScript (which can throw "errors" if written incorrectly).
If you stick to text files, you'll never have to go to caniuse.com ever. Need styles? Just make a PDF and throw that online. During the "XML HTML" phase the web went through, I never had to worry about validating my PDFs through an XML validator. Then when everyone decided using "<b>" and "<font>" tags was bad and insisting we switch to using "font-weight" CSS in a completely unrelated part of the file, guess what I had to do? Nothing! My PDF keeps rendering exactly the same way through every silly "trend" and "update" on the web, and never misses a beat on Lighthouse in Chrome.
Now if I could just convince all the browsers to implement .docx renderers out of the box, I'd really be set.
Good luck having your site be easy to read on both mobile and desktop with either of these approaches. text/plain may work if you use soft wrapping, but even then most desktop will need to resize their browser window to make it narrow enough to read comfortably.
> HTML is subject to different renderings on different browsers
This only matters if you actually care about exactly how your website renders on any given browser. Most websites don't have any need to care. PDFs are the worst for this: They care, A LOT. Which means locking you in to some hideous rectangle that's a different aspect ratio than any monitors I own, locking down the fonts and colors so that I can't just rely on system defaults, etc.
If all you need is to convey text, and maybe take some input, HTML is a fantastic solution.
> Originally this website's font-family simply requested monospace. This approach resulted in varying reading experience depending on the OS. Windows browsers got Consolas, Linux users got DejaVu Sans Mono, and macOS people got Courier.
I find it so sad that our browsers have such bad default fonts that all websites feel the need to override them to get an acceptable look. It would be great if browsers had decent defaults for both the overall default as well as serf, sans-serif and monospace so that most websites who aren't worried about font branding can just stick with the default and users can get a good fond, or even their preferred font if they bothered to customize it.
In my experience the default fonts on Apple devices are far and away the best fonts, period. They're better than almost every custom font, especially for readability.
I don't have an Apple device to test but does that mean that the author's point about the default `monospace` font "Courier New, is not legible" is out of date or just a rare opinion?
I think Courier is the only one of the fonts listed above that’s not sans-serif. The retro typewriter effect is not probably not what he wants for displaying a lot of prose in a modern context. I don’t think it’s actually illegible.
Probably very subjective. I, for one, am still using Courier New as my main monospace font, especially for code, and actually prefer having typewriter-y "serifs". No other serif-y monospace I've found fitted.
I don't mind Consolas, and I like what is author using now (DejaVu Sans Mono), but their stance about varying reading experience depending on the OS makes me really, really devastated, because it just reflects a sad state of IT literacy and general adoption of basic philosophy of the web, which was built on premise that how content looks like depends both on author and user (through user agent) and fact that generic font family looks ugly is in other words defaults are bad combined with users have a bad taste and set bad default values.
As was said, we are supposed to express our preferences in (through) our (user) agent's preferences.
Most probably your browser will use four distinct fonts on this page, *all* of them (and more) you can define in your browser's or operating system's settings:
Fun fact: even though author have expressed a lot of opinions in their CSS, still for me the result is probably different from what they expected: since author does not define font colour, I see it in my default (not black but dark brown), plus paragraphs are slightly indented for me, since I limit their maximum width through userstyle. Funnily enough, background colour that author chose (and set, #F5F5F0) is nearly identical to my preferred background colour.
Authors defining background colour without defining text colour is the reason we cannot effectively have default dark background and light text default in our UAs, because in this case we would see authors (light) background and ours (light) text.
At least on linux, it's not the browser that picks the font used for "monospace" but part of fontconfig. I've reconfigured my fontconfig to use a different font for monospace.
At least on Firefox it is both. By default it uses raw fontconfig for default, serif, sans-serif and monospace. But it uses an override for emoji fonts. You can also explicitly override these in the preferences and then it doesn't consult fontconfig (or probably consults it with a precise font name).
But yes, I have seen decent browser fonts for most Linux distros.
Consolas is not bad. DejaVu is not bad. Only Courier/Courier New are so bad as to be unusable, it seems Apple wants to push web developers to use font overrides.
It is a bit odd that "monospace" in a mac browser gets you Courier/Courier New, because macOS has come standard with Menlo for ages and Monaco since the OS 9 days, both of which are excellent monospace fonts that are far and away better than either Courier. Even weirder, outside of browsers requesting a monospace font will get you Menlo.
Newer releases also have San Francisco Mono that it could use instead, which is even better since it's tuned for modern displays.
Apple is notorious for wanting to push people away from portable and easy-to-use web applications to non-portable, expensive to develop, and frequently worse mobile apps.
It’s more that they don’t put the high level of refinement into the web experience that they are famous for in their native (Mac/iOS) applications.
Though of course there are plenty of discontents with that. On balance I think the apps that ship with MacOS are much worse than their Windows counterparts. I think iOS on the iPad is truly superior but the settings app is dark pattern city, particularly the notification that never goes away about the Apple TV trial that is about to expire but actually expired years ago.
DejaVu is not a websafe font, meaning you cannot rely on it being available.
Why we can't just require browsers to include DejaVu or another open font is another question - not like the size matters compared to all the other crap they ship. Heck, some even ship their own fonts already, but only for emojis.
Even having some defined meta fonts with rough metrics so that you could say font-face: monospace-standard or whatever and have the text be roughly the same size everywhere would save so much effort and wasted data.
> Why we can't just require browsers to include DejaVu or another open font is another question
Including a small set of open fonts does seem like a good idea. I'd like to see Inter UI[0] included because it's a very nice screen/UI-optimized font would serve a similar purpose as "system-ui" does now, except without some of the pitfalls[1] that comes with.
Courier New is the most appalling piece of shit I've ever seen in my life. It's ugly at small sizes, jagged and unpleasant at medium sizes, and abhorrent at display sizes. WOW do I hate Courier. I hate it on Git Bash. I hate it in cmd, I hate that it exists. Consolas, by contrast, is lovely and beautifully-hinted at best, and inoffensive at worst.
Don’t lump Courier and Courier New together. Courier (which Apple includes) is fine; it’s only Courier New (which Windows includes) that’s atrociously light, because it was digitised very badly incorrectly. It actually used to be not so bad, because they kinda patched it to make it usable with hinting, and then special-cased it in ClearType, but those don’t really go far enough and aren’t consistently reliable anyway, so it’s just an awful font.
> even their preferred font if they bothered to customize it.
Felt. I actually do adjust my user agent fonts and system fonts, and I hate it when these "system UI font stacks" aren't just "sans-serif" and I end up with Arial or Ubuntu because some guru said this is how you do it. Especially irksome though is the monospace fonts--either Courier New (which hints way too thin to be readable on my main display) or using some hard-to-decipher custom font that abuses ligatures.
Yes this! If I make websites as a blind person, I'd probably just have CSS give headings 20 PT font size, paragraphs line spacing 2, 16 PT. Something like that. But if browsers used good defaults I could just not worry about CSS and just go with plain HTML.
It's well past time for browsers' reader modes to be the default experience for unstyled pages. The arguments for not doing this—and keeping a single set of user agent style sheets containing rules that have to match how unstyled pages looked in the 90s—come from a place of good intentions, but are ultimately poorly reasoned and result in one of the worst forms of stop energy. (The strongest argument against is: "my browser's reader mode is worse than the unstyled page", which I sometimes agree with, but is still not a very good argument at all. It's solved by fixing the reader mode itself to be less bad.)
The bad fonts can be tweaked ever so slightly to remain eminently familiar and inviting, but slightly adjusted in positive ways.
It could be kerning, leading, default font size, all come together in very powerful ways before finding a very specific font to enhance the brand experience.
If we look at HN, the window we type a comment into continues to use a font when writing that can help induce more awareness of writing. Maybe it would be slightly different if it was a blinking square cursor. Or a slightly taller box.
They solution IMO is not to rely on default browser fonts but rather to pick a stack that’s available at the OS level.
On my site for example, I designed everything using Iowan as my main font because I know that it’s available on most Apple OS but then I manually picked a few fallback fonts that should be available on Windows, Android and the rest.
Default serif is just the last option if everything else doesn’t work.
I noticed the web site has a downloadable font, which is fine as long as it's optional, the problem is that many web sites have the bad practice of using the private unicode range for icons. Now the web site has become an accessibility problem. Downloadable fonts are optional, and there is no fallback mechanism like we have with img and alt text.
I'll happily lump JavaScript in as a major accessibility concern. JS is most often used where it shouldn't (most recent in memory is the Unreal Engine docs). Using JS for such simple presentations is like building a 5000-story building to print a sheet of paper, when all you needed was the pre-printed sheet of paper (HTML, CSS).
This is what you get when you prioritize companies over users.
There's no reason websites should even be able to set the font in my browser.
If it was just about websites achieving an acceptable look, you'd see people emulating industry leaders, but that's not what you see. Google, for example, uses Arial on its main page on my browsers at least--that's a font that's available on every browser I know of. If it's acceptable for Google, it seems like it's just acceptable in general.
Instead, the fonts being loaded are about websites achieving their own brand. I've built a lot of web frontends, and every time I get a rebrand contract, the designs I get contain a bunch of fonts.
As a user, I don't give a fuck about your brand. Being able to read your fonts clearly is a much higher priority for me than experiencing your brand. Fundamentally there's no reason at all that sites should be able to decide for me what font I read. I am lucky to have fairly good eyesight and no serious processing disorders, but users who have these issues are seriously negatively effected by sites overriding their browser defaults. And since few projects are given adequate accessibility budget, users are left with no recourse. Overriding a website's fonts with your browser settings doesn't really help, because sites often use pixels and other dimension units that make your site unreadable if you use a different font than what they tested with.
As I said, "Overriding a website's fonts with your browser settings doesn't really help, because sites often use pixels and other dimension units that make your site unreadable if you use a different font than what they tested with."
Of course that can also be fixed, but there's only so far you can take this. I have the technical ability to edit CSS, but I don't reasonably have the time to do it for every site I visit.
Firefox: Settings → Fonts → Advanced → untick Allow pages to choose their own fonts, instead of your selections above. It’ll still load web fonts for Private Use Area code points (icon fonts) and Google’s misbegotten Material Icons with its awful ASCII + ligation technique (see the browser.display.use_document_fonts.icon_font_allowlist pref in about:config), but other than that will stick with your preferred fonts.
I tried this as a two-week experiment a year ago. I’ve never gone back, it improves the web so much.
(Well, actually I also block web font downloading altogether, for no particularly good reason, at the cost of icon fonts and Material Icons breakage, but it doesn’t often matter.)
Same here, my Firefox has disabled "allow pages to use choose their own fonts" for ages. I do use Stylus to override a bunch of fonts/sizes in various sites too.
This is completely false. Both use images for the board and pieces, so you can play just fine.
Both do use icon fonts for some of their additional controls on the right hand side, but they all have tooltips so that you can identify them even without the icons. Chess.com uses a bad icon font that uses non-PUA code points (e.g. V = New Game, , = Move Back, … = Move Forward, g = Show Hint), so those ones will be broken. lichess.org uses PUA code points (except for “½” for “Offer draw”), so I think that those icons would even be loaded if you weren’t like me in just blocking web fonts outright.
Because a lot of people don't have the technical ability. The tab is called "Advanced" for a reason.
It quickly gets more complicated for some sites, which users might use often. There are folks talking about how you can use custom CSS to fix just about any site, and that's true, but how technical are we expecting users to be?
And even as a user who develops websites for a living and can definitely do all this, I don't want to. The web should be designed to work for users by default. I shouldn't have to fix websites to use them.
> Because a lot of people don't have the technical ability. The tab is called "Advanced" for a reason.
Come now, it doesn’t take any technical ability to use the checkbox. It’s called “Advanced” because it’s more complex tweaks that most people aren’t interested in and which take a moderate amount of space so they want to keep it out of the way lest the page get too long, not because it’s hard to use in any way.
> It quickly gets more complicated for some sites, which users might use often.
It is rare for this to have any ill effect on any site (icon fonts that don’t use the PUA and aren’t Material Icons (for which Firefox has manual exceptions in place) are about the only case, and they’re distinctly rare nowadays—I only recall encountering about two cases last year, both of which were paired with labels and thus unimportant), and in those rare cases it’s unusual for it to be a real problem (they’ll almost always have labels or tooltips).
I will quite happily recommend changing this setting to completely untechnical users. It occasionally causes very mild harm, and can theoretically cause great harm for particular sites (but I haven’t found such a site for years, and any such sites were surely already broken anyway), but the rest of the time it improves matters markedly.
> Come now, it doesn’t take any technical ability to use the checkbox.
It's clear that you don't interact with average users very often if you think this.
Obviously you can direct the user through to the steps to check/uncheck a textbox, but understanding what that checkbox actually does and why they might want to check/uncheck it is far beyond the technical understanding of most users.
Recently made my first blog/website and used NextJS. It’s been fun adding style and bloat at this stage since everything I do is for learning. But I wonder how many years go by before I opt for something more basic?
He talks about the evolution of his blog in this post[1] and has a link to the web archive of an early version.
It’s nice to see a “You don’t need X” article that isn’t just annoying snark. This actually answers some questions people had, which feels like a much better reason to write something like this, rather than the usual rage-bait “you don’t need JS/CSS/Framework/Technology considered harmful” medium articles.
There's definitely a lot of websites out there that are just super dynamic and flashy and complicated in ways they don't need to be, and I mean that to the owner's detriment, not necessarily the reader's. How many hacked Wordpress sites didn't even need to be Wordpress in the first place? If you don't have comments on your site, you probably don't really need Wordpress, and even if you do a Disqus-like solution on a static site is probably still more secure. Which, again, I mean in terms of bothering the owner, not just the users.
I think articles that are just all about how you're bothering your readers can be a bit tedious, but there are ways even the owners are hurt by the belief they need every whizbang thing, because they all have maintenance costs and general quirkiness costs associated with them too.
As someone who uses a static site generator, I agree with most points. The most important thing in a blog/website is the content. Start writing, and publish.
As I sit here several minutes into a build powered by gigabytes of modules and package artifacts that is converting a collection of components into react-native, then converting the 30-page react-native mobile application to HTML using react-native-web.
One problem not listed is source code syntax highlighting. If you provide source code listings in articles, then highlighting is a big help to readers. Generating it in HTML is not fun.
Pygments does this easily, depending on the source for generating HTML pages. It has been available for a long time. For more than a decade. Some blog generators use it, not only Python blog generators.
Alternatively, you could specify the type of the source code so the user agent could handle the syntax highlighting—just like every other source code viewer ever written aside from those with idiosyncrasies related to the fact that they that belong to a special class called "Web browsers".
Tbh <pre> + monospace font + padding already makes a lot of code snippets readable, you can also write a 10 line js function to generate highlight for only the comments (to make them lesser shade of gray), i think that solves a lot of readability with very minimal work. Also I think there's no shame in using highlight.js
I sympathise with the main thrust of the post but, to nitpick, this is just plain wrong:
> But mostly css appeals to our vanity and ego.
Design isn't just about aesthetics. Good information design, clear visual hierarchy, accessibility, etc. all help with communication. The author's effective use of spacing, bold, and code tags show us that they know this intuitively, despite what they write.
I agree, I get the idea that a blog doesn't have to be fancy, but a simple css theme with nice spacing and good font size goes a long way. The examples they show makes me click away instantly, because it is so damn hard to read.
Also possible the typeface is compatible with the readers and the content they regularly consume.
Hell, that typeface is something anyone is subjected too if you do anything long enough.
The experience of getting to imagine how much thought goes into laying out text on a typewriter is something I think should be for everyone to try at least a few times.
As a good example, his site is very readable (because of the limited width of lines), and the sites he linked to that were largely unstyled were very useful, but not very readable. It would be worth it to me, as a user, to use a browser plugin to add a few lines of CSS to those sites before I dove in.
I'd say HTML for itself just gives us a way to give meaning or imply how something should be styled "headline of first order". In the end it's a markup language, not some magic styling tool.
How it is actually styled (in absence of CSS) is in the hands of the default rendering of your browser. That might very well be a very bad rendering, due to lack of knowledge/time/engagement of the people building/maintaining that renderer.
Also those renderes might come from a time and system where technical limitations where different, markup was different, lots of things were very different.
So I don't think we should expect HTML alone to "look nice" or work well in regards of readability.
> I'm quite certain that a large part of the web would need no CSS or just a few lines of it, if the basic (browser applied styles) were good. As in: designed
I think we would win a lot if browsers default styles were beautiful (as in: really good, not merely fancy) designed. Many websites then would need just a few lines to set some colors, style that weird-custom thing they do or make it feel just a bit more personal.
I think the bigger thing would be to have more semantic HTML. <dropdown>, <tab-area><tab>Content</tab></tab-area>, <carousel><slide>Content</slide></carousel>, <rich-text-editor>, etc. Instead we've got a million immature implementations of these that are slower because they are written in JS instead of native code, slowly break over time as they aren't maintained, and typically have terrible accessibility.
Well, that was what HTML was on track to give us. But once JS and CSS were introduced, semantic HTML that was actually semantic stopped developing, under the assumption that if someone needed, for example, a tab area or slide show, they could develop those themselves with CSS/JS. What we've gotten instead is extremely vague elements like "section" that don't communicate what the elements are.
If HTML were truly semantic, browsers could implement accessibility features around it, but because they're so vague, there's no real way for browsers to do that, which offloads the responsibility onto web developers, who in most cases aren't granted budget to do it. There are a handful of features such as alt properties, but these are pretty limited.
So yeah, HTML should give us that, but that's part of what users gave up when we decided it was acceptable to allow random websites to run code on our machines and tell us how our content should be displayed.
I agree with you, but also I think the section tag is one of the biggest leaps forward we've had. Putting an id on a whole section instead of a name= crap for references, and actually using nesting for hierarchy.
All the HTML5 input types are also an example of semantics impriving. It could be way better, but it's not a total stalemate
> I agree with you, but also I think the section tag is one of the biggest leaps forward we've had. Putting an id on a whole section instead of a name= crap for references, and actually using nesting for hierarchy.
How does this differ from how <div> was being used before?
I've switched to using <section> simply because it's a better name, but I'm not sure it's made any meaningful difference in my code.
Another example of the pointlessness of this issue is <em> and <strong>. I've rarely seen code where these weren't used exactly the same as <i> and <b> were before. In rare cases, I've seen someone do something like make <em> a different color rather than italic, and that's almost always been a bad idea, because when HTML authors use <em> they almost always intend for it to be italic. In fact, I'd say we should just continue using <i> and <b> because those communicate intent better, but at this point I've worked in too many codebases that decided that <i> could be hacked to mean "icon" (i.e. using FontAwesome) which is a horrible, awful, no-good, bad, hack.
> All the HTML5 input types are also an example of semantics impriving. It could be way better, but it's not a total stalemate
That's true, but I think we'd be moving forward a lot more quickly if we weren't devoting most of standards development resources toward giving companies more fine-grained control of our browsers through CSS/JS.
My e-book reader shows <em> text with teal color and I like it, it's better visible than italic and the font remains upright and readable, I doubt it will be comfortable to read lots of text in italic. I didn't notice any discrepancy with <i>. But for some reason <strong> doesn't override <em> and they multiply, though I saw it used once when an exclamation was repeated several times with increasing emphasis for extra dramatism.
There was never a golden era like you describe (it was a time of conflicting philosophies, people saying "eh, let's add this, that would be sweet", and browser vendors competing to add as much as possible to out "innovate" each other and the limited specs), semantic HTML helps in some cases but is never going to give you automatic accessibility, and a one size fits all browser style is still not going to give you what you need even as you add increasingly unsemantic tags to try to improve it (which is exactly what was happening pre-CSS).
> There was never a golden era like you describe (it was a time of conflicting philosophies, people saying "eh, let's add this, that would be sweet", and browser vendors competing to add as much as possible to out "innovate" each other and the limited specs)
I did not describe a golden era of HTML, because a golden era of HTML never happened. Instead, it was precluded by the introduction of JS/CSS. Had JS and CSS never been invented, we might have achieved a golden era of HTML, but we would have needed web standards to mature before that could happen. What happened was, web standards did mature, but they matured to serve websites rather than users. As a result, mature web standards center around JS and CSS, leaving HTML anemic and weak.
What we have now is a time of conflicting philosophies, with websites competing to add as much as possible to out "innovate" each other. Users still suffer the same inconsistent interfaces they did in 1997, it's just that instead of browsers being inconsistent, it's websites that are inconsistent.
Well, there was a previous garbage area, when HTML was, rather than being semantic, laid out using tables and \<color\> and \<font\>. I remember telling people to not do that, especially when the first version of CSS came out, and you could make websites look nice with semantic HTML that also worked in Lynx.
Table layouts are still superior to CSS in that they achieve the Holy Grail layout. As far as I'm aware, CSS still fails to achieve the Holy Grail within any reasonable realm of effort.
Hell, the entire reason the internet moved from Holy Grail layouts to singular sidebar and vertically integrated layouts was because CSS can't into Holy Grail.
With how wide most users' monitors are ever since 16:9 became commonplace, Holy Grail should be the ideal content presentation layout because it uses all that free space on the sides for non-content (eg: navigation) so precious vertical real estate can be dedicated to content.
This doesn't add up. CSS grid, flex box, etc all do the "holy grail" layout with a couple lines. The tables mess that was early www was and remains an absolute mess of markdown to maintain for layout. Semantics and accessibility are practically out the window with table.
HCI dictates how humans use interfaces and with that comes many defacto reasons why a plain text page does not solve the problems users want to solve. Do you not think websites test into the optimal performing layouts and content distribution? If it worked better, we'd all be using it (it doesn't).
It would be so great if there were more built-in interactive elements like tabs, modals, and tooltips. How many times have these incredibly basic things been re-created?
Yeah, all this time browser vendors should have been taking a "pave the cowpaths" approach to natively implementing stuff that everyone ends up reimplementing in CSS and JS. And HTML5 did a little of this, with e.g. date and color input fields. But they could have gone farther.
To disagree with my own point a bit, it’s unfortunate that the controls HTML5 added look different in every browser, and can’t be styled with CSS at all.
Yes. HTML gives the structure and hierarchy (if done properly) which is also what then gives the accessibility. CSS can do lovely things that will help a blind user with a screenreader not one bit unless you're kludging in "hacks" to give them extra hints for specialized use.
It's also a great example of how even such a little can go wrong.
The CSS of the second website is wrong, as it uses 'color' without setting 'background-color'. Assuming anything about the default background color is not possible because it is user-configurable in most browsers.
At least http://motherfuckingwebsite.com remains readable when you change your color settings (the second one is completely unreadable on my browser).
<style type="text/css"> ? what are we dinosaurs? You might as well leave out the closing <p> tags if you are going to be like that.
If the whole point of your website is to brag about code to accomplish reasonable formatting.... can we at least have code formatting? I think I have enough bandwidth to afford some line breaks.
Clicking on the first website, I can't even view it because it's asking
for captcha.
So, to extend your comment: you do not need to worry about content if your
website isn't even reachable. A GET request should never result in the client
being bombarded with captchas. Unless you have a sure fire way to determine
if said client is a human or an evil AI taking over the world (nobody does),
just serve the damn page.
Yeah, I actually like the oldest of the three best. The one with 7 css declarations was annoying to me somehow and the third option was garbage. I miss websites that were about conveying information.
The default Emacs theme is not great, but the current best practice is to stop messing with themes and just use modus (vivendi or operandi depending on your light/dark preference), especially since they are now included as part of Emacs.
In my mind "raw browser" look corresponds with "almost insane details coming" as the only sites still using that are often run by people who are WAY more concerned with the content they want to talk about than with the presentation.
Um, shouldn't all people be WAY more concerned with the content than the presentation? I don't want to read stream of consciousness with occasional lack of spaces and random case, but I'd really prefer to only read websites by people who give zero effs to presentation, and I had prior to this moment assumed everyone agreed, but that it was fun to do presentation, so people did. There are people who care about the presentation of what they are reading on even close to the same level of the content itself?!
Totally agree. For me, the original is far easier to read than the "better" or "best" versions.
Initiate rant mode:
- The gray on gray is like a joke, except it's not. I get the theory and alleged benefits. I get that some do prefer it, especially for IDEs. I get that some are happy to see (or at least apply) it all over the web. It just does not seem to apply here. Man alive. Literally making it harder to differentiate the text.
- I don't mind adjusting the browser width to get the lines exactly the right length for my screen and reading preference. Actually, I far prefer it over all the other options. This is like a tragedy-of-the-commons or lowest-common-denominator or dumbing-down-on-the-false-premise-of-being-smart issue. Instead of utilizing what we have, and encouraging people to learn and become capable with the simple and flexible tools, it's one size fits all (or, you pick the size you think I want). Only it's not.
LaTeX predates HTML by a decade and supports pictures, charts, quotes and far more, and doesn't force me as an author to make finicky decisions about presentation. I just write the content, and then set the document class to whatever the publisher wants.
I was happy to see someone finally referred to the motherfucking websites.
On the other hand, I was disappointed to see the unique one of those I think it is worth to follow the advice [1] was not cited.
For curiosity reasons, I found out about [1] on a well-known website [2] that definitely puts content in front of presentation, even though I like their website's design.
The source is on GitHub, you're basically looking at "machine code" for the browser. But if you want to verify it's the same code, it isn't obfuscated, so just run a beautifier over it and compare. Best of both worlds.
prose.sh hits a sweet spot for me. Not just in the minimal-but-rich-enough presentation of blog posts[0], but also (off-topic for this thread I guess) the simple interface: just scp your markdown to prose.sh.
Could you elaborate? The first one is uncomfortable to me if you have a large browser window, because the lines of text are so long and it’s hard to follow. The second one at least fixes that problem.
I’d never seen thebestmotherfucking.website! I appreciate the nuance it adds. I don’t have any nuance of my own to add right now but I do have to share my amusement at the empty list item under contributors. I figured there would be something in the source referencing someone (similar to how some folks on Twitter make special acknowledgments for people not on Twitter), but if this was that it’s a very Inside Baseball reference:
<li><a href=""></a>
</li>
Or it could be a joke about copypasta in hand-authored HTML. Or just actual copypasta. Who knows! But I enjoyed it.
You make it sound like an unequivocal truth; it isn't really so. I launched my own hobby website/blog only after I designed my content presentation. It helped me understand what I was writing. Of course I had the underlying drive to write something already, and was not coding up some CSS without a vision.
Everybody finds their writing juices differently. Push where it means you'll write more.
I think the main point is that, balance is also a very important design decision. A bit of CSS can go a long way; a lot of CSS can become a nuisance. There is definitely some 80/20 sweet spot where you get most of the design you need from a little CSS; finding that sweet spot is the challenge.
Javascript transitions/animations, on the other hand... yeah. I won't got there.
I've been arguing that HTML would've been a much better information-carrier if "basic browser styling" did this. I'm quite certain that a large part of the web would need no CSS or just a few lines of it, if the basic (browser applied styles) were good. As in: designed by (information) designers. They could even differ per browser, as long as all of them were good (or really good).
But alas, base styles are a mess (yet still there!). They do have some hierarchy but accessibility and readability are bad. That's aside from aesthetics: just stuff like alignment, spacing, fonts, flow: very poor.
I am aware that more base styles would make that cursed "reset.css" even larger, but I guess if a large part wouldn't even need that, it would be fine. It would be a situation where everyone can choose "good styles" or "spend lots of effort to get even better, custom, styling", rather than everyone "spend lots of effort to get an even decent styling".
Honestly - it'd be pretty nice to be able to opt-in/out of the default user agent styles applied by browsers. If we really want to preserve compatibility - opt-in to a version.
Keep it all the same as current if there's no tag on the page, but if you add something like <meta uastyles="1.0.0"> or something, apply an improved set of default styles.
Get rid of the need for resets with <meta uastyles="none">
Basically - I'd love a way to allow browser vendors to dramatically improve the defaults without breaking everything, and also giving frameworks an easy opt out.
I agree that defaults are not perfect, but I'd like to add that the initial idea was that they are, well, defaults, and you -- as a user -- are supposed to adjust them to what you prefer. In some dashboard usually called "preferences" or "settings". And fact is that you still can: you can tell your browser "for this script, for serif, use this font family, for sans use that one" etc etc. You can set you preferred text colours. You can even write your own style that will sit between user agent styles (those "ugly defaults") and author styles (those forcing weird stuff). Initial idea was that our browsers will be truly individual tools and one of their main task will be consolidating those preferences from various sources. That's the "cascade" in the CSS.
Yes, I know. Back in the fun days when a browser was supposed to be my "user" agent. Before they became the mini-os they are today.
There's nothing here that would stop you from still doing that.
But if we're talking about practicality... I think far more people would get a benefit from improved defaults (as long as they're not breaking existing sites).
While I've modified the user styles for my chrome profile as a part of being a web developer, I'm not aware of a single non-developer acquaintance who has (literally - none). Honestly, not even many of the devs I've worked with have done it.
It's just not all that relevant when the defaults are so bad that all the sites are overriding them anyways. Makes it very hard to apply a set of user styles that's sane, so no one does.
Make the defaults better, and maybe you can end up back there.
I want to hug this whole thread. Yes, 1. browsers should improve their defaults. 2. web sites should respect user preferences over their own style, if the preferences are set. 3. browsers should make user preferences more prominent and provide an easier way to override web sites that refuse to honor them.
My browsing experience should not be determined by an artist or product designer 1000 miles away from me in an office somewhere.
My language skills and time pressure fails me here, just wanted to express general "thanks folks" for your reactions as well. Seeing that someone shares similar point of view on this topic made me surprisingly very happy, so thank you again.
A lot of these things were handled by one typeface on a typewriter so the premise isn't entirely unfounded.
Visual communication and design predates CSS. Information architecture, design, guiding the user through the message is definitely a skill.
CSS can do as much distraction as it can enhancement. It's one appeal of Tailwind, it's more than serviceable while learning about the design, hierarchy, and flow.
100%, and calling aesthetics an appeal to vanity and ego is a reductive take. I love that individual’s websites have different styles which reflect either them personally or their brand.
That can mean going all out in design, or having an HTML-only page like nothing. Both have value in their own way, and should reflect the creator to some extent.
Even folks who say content needs to be figured out before presentation... it's not so cut and dry. Your medium shapes your message - they are not mutually exclusive and for the receiver of the message, the medium matters for their reception of the message.
I understand the sentiment that TONS of CSS is probably a bad use of time. But trying to demonize or otherwise attach aesthetics the label of "meaningless" is, in my opinion, just as much egocentric as they claim CSS to be.
> scroll the mousewheel: giant footer section slides up taking half the viewport
> move the mouse cursor up: giant ass header slide menu drops down covering half the viewport
should be absolutely no motion on a page unless i specifically click on something, like play button or slide out button. and that includes parallax bullshit.
prefers-reduced-motion should be the DEFAULT not an override. ffs haven't we learnt anything in the last 20 years of web dev - you cant rely on web monkeys to build things right (\s).
---
and f*k you to whoever thought having mouse hover popup autoplay boxes on youtube was a good idea.
In my personal, obviously anecdotal, experience it's always the "technical" guys who think things like this. This is why we have UI/UX teams and we don't let programmers create visual interfaces.
Because reading words requires substantial styling enhancements over what the browser is already capable of? Has anyone picked up a book lately?
You need a UI team to create a page of readable text? That sounds like an expensive waste.
But it sounds like those 'UI' people think they know better and don't need suggestions from programmers about reading words, even though its what they do all day.
It's very funny that you seem to think reading code and reading a website are the exact same type of activities, and the same type of reading. They are not.
And I don't know where you've been for the last 30 some years, but the web is not a text only format, and the reason HTML was invented was specifically to be able to create a designed space where text can actually make sense and is not a gigantic wall of impossibly small black on white text.
Sounds like you ought to be doing the Richard Stallman approach to reading webpages and not commenting on whether or not CSS and design is needed. Back to the terminal with ye
Sounds like you should do less stereotyping of roles. You’re assumption that programmers don’t understand UI and need to stay away is exactly what the blog refers to when talking about ego. You think programmers output all their work in a terminal?
I understand this and that's all well and good. Many (but not enough) offer "print" versions of pages, which could and should be translated to "text only" versions of pages. This isn't my issue. My issue is these <redacted> imagining that the web outright doesn't need design at all and that CSS is a terrible waste. And to me this is just about the most dull opinion on the subject that I can think of.
> My issue is these <redacted> imagining that the web outright doesn't need design at all and that CSS is a terrible waste.
While you do have some going to that extreme, I think it's mostly pushback against the insane amount of bloat and overbusy design out there. Some CSS can be useful, to improve readability and offer a little visual appeal. But I think maybe you missed my point.
Traditional books are typeset the way they are for a reason. No or minimal pictures. Block after block of text, broken up and spaced for readability, comprehensibility, and flow. Different types of books are laid out differently, but they mostly follow this theme. It's highly effective.
You kind of broadly have 3* categories of web pages on the web, as relates back to print:
* Book-types (mostly text in nature)
* Magazine-types (more about graphic design, with content mixed in)
* Advertisement flyer-types (sales pitches, mostly about design)
These are going to have different design requirements. There's plenty to write on the subject of design for these categories, but in the interest of getting to the point: there's an awful lot of the first category on the internet, and it really requires very little in the way of CSS. It certainly doesn't require hero images and 10MB of javascript. Blogs should read like newspaper articles, technical content should be typeset with similar minimalism to technical papers or books.
* There's a fourth category: webapps. My personal stance is that these don't belong on the web at all, but given that they're going to be, they obviously have far different design requirements, and are quite outside the scope of this discussion.
If your idea of a good site is a 3MB monster full of useless whitespace, hero images, carousels, hamburger menus and other modern design trends, maybe that's a sign we shouldn't let designers create visual interfaces.
I really dodged a bullet there huh? Since that isn't my idea of a "good" site necessarily. But if your idea of a "good" site is all function and no form, then maybe stick to designing abstract interfaces and not things actual people have to see.
Why are you even browsing websites that have any design then? Why are you even browsing in anything other than lynx? Please spare me seeing that ideologically boring site again
Like I can barely imagine what your house might look like. Just like a purely functional weathered hovel with the absolutely barest essentials. A perfect prison cell
I like it because it means they will never be my competition for anything but incredibly niche/domain-specific boomer software people have no choice but to begrudgingly use.
But, you can get all of these things from HTML. Especially visual hierarchy and accessibility. The cornerstone of accessibility on the web is: does it display legibly and is it navigable without any CSS? CSS is eye candy. It's aesthetics. Those are not without value, but the value is not in the things you list.
Why dismiss aesthetics out of hand like this, equating it with vanity and ego? Aesthetics are very important to people, possibly even more so than the information on the page.
Obviously, that depends on the purpose of the page/site. If the page is a brochure or advertisement, content is almost irrelevant; you could link to it, for buyers that wanted content. Brochures and ads are about feelings, and aesthetics are about feelings.
That's not what I think the www is for, but not everyone agrees with me.
FWIW, I agree with you (and I don't see where I dismissed it), but the point is that even a certain type of utilitarian-inclined programmer is wrong on their own terms.
It's also the case that the default stylesheets for the web are terrible, for historical reasons. If the default stylesheets were reasonable, then at least 80% of the time you could just use semantic HTML5 and be sure that your presentation was at least OK in terms of visual hierarchy, accessibility, etc. As things actually stand, you need at minimum "100 bytes of CSS to Look Great Everywhere", and if that doesn't meet your needs, a classless stylesheet.
As always, I think the custom font hate is overstated.
> Custom fonts are a waste of bandwidth
Latin subsetted fonts are generally 10-30Kb, it's really not that much. For comparison, it's unlikely you'll see blog authors get up in arms over a single PNG.
> they come with one of three evils called latency, FOUT, and FOIT
A few milliseconds of a different font appearing is truly not much of an evil, but can be addressed by exactly what the author links in their footnote.
Humorously, the author's own site is committing some sins here: both of two font files are >140kb, they don't have gzip on, and they have the fonts marked `font-display: block`. They could cut their CLS and LCP by almost 100% by addressing this: https://i.imgur.com/MOl32iS.png
Of course, it's already very fast, by virtue of having no other resources loading. This would be dramatically worse if there were scripts that needed to get downloaded.
> Latin subsetted fonts are generally 10-30Kb, it's really not that much.
Agreed. Make your own custom font files with only the characters you use, or are likely to use.
> A few milliseconds of a different font appearing is truly not much of an evil, but can be addressed by exactly what the author links in their footnote.
Browsers will wait for about 3 seconds for custom fonts to load before showing a fallback font.
> both of two font files are >140kb, they don't have gzip on
woff2 format fonts are already compressed, so gzip won't do much.
> Browsers will wait for about 3 seconds for custom fonts to load before showing a fallback font
Depends on the `font-display` value on one's `@font-face`, which is where the author's choices of "latency, FOUT, and FOIT" comes from. For instance, Google Fonts uses `swap` by default, meaning the fallback shows right away: https://web.dev/font-best-practices/#choose-an-appropriate-f... (I also think Safari's `auto` font-display never shows fallbacks, but that may have changed)
That's often enough. You can go another step further and preload the font, which I generally recommend. This especially helps if the font is otherwise discovered late by the browser.
Yeah that paid hosting + dns services combination is complete overkill when going for static html.
I host a bunch of files and static html on my domain and I’ve moved it to github pages. The dns services bundled with the domain at gandi are enough to set it up on top of the free github pages, so my hosting is effectively free, and if I wanted I could still run a site generator.
Static html gets even easier by using something like simplecss, because that gives a basic design with zero effort on top of semantic html. https://simplecss.org/
"If you can stick to the same style long enough and also write articles for long enough, your style sheet can become your brand. But mostly css appeals to our vanity and ego."
This is blatantly incorrect or a flagrant misrepresentation. CSS can certainly improve readability without adding design.
Readability is a check list which stock HTML does not address.
Also : there is a background color specified, but other colors are not overriden, which causes the text to appear in a color very close to the background color on my browser (the default text, and background colors are user configurable).
> Inevitably, you will want to do something the framework did not forecast and will come up with convoluted ways to do it anyway.
I always find static site generators a kind of leaky abstraction. They eventually try to abstract nearly the whole functionality of the web stack, and the larger the SSG the more apparent it becomes. But, for obvious reasons, they just cannot abstract all the peculiarities of the web from you.
I write posts in Markdown, use Pandoc to convert `.md` to `.html` and a simple Go script in 200-300 LoC [1] for my https://hirrolot.github.io/.
> A host for your index.html files Hostgator $33/year plan.
- Google Cloud Firebase Hosting - free; really good tooling to deploy, automatic CDN
- AWS S3 + CloudFront - a bit more setup, but more or less free
- Azure Static Web Apps - free
No need to have any hosting plan.
Firebase Hosting in particular is really easy to get started and connect a domain to it. The Firebase CLI tooling makes it dead simple to deploy updates as well.
If you are OK with just having an IPv6 IP, you can live in a country like the Netherlands and simply use your home connection to serve your Web page. Almost like it was intended by forefathers...
But, really, in my dream world, ISPs would also act as registrars for their clients, so, once you pay them you get some automatic domain name, or maybe can pay a bit extra for a permanent one that you can take to the next ISP you sing with.
> "This website used to be hosted by asmallorange. When I became dissatisfied, all I had to do was to open an account on hostgator, upload my html files, and change the DNS entry"
At the risk of being pendantic, asmallorange and hostgator are owned by the same entity[0].
That said, I like the premise of just writing and producing content and not necessarily worrying about setting up tooling. I think devs, and "geeks" in general, tend to enjoy tinkering with tooling, but it can be daunting for the less tech savvy. I suppose that's why things like Wordpress.com exist.
A small orange sure has changed. It used to be dirt cheap crappy shared hosting. Now it's expensive compared to just getting a full VPS nearly anywhere else.
Their VPS offering is $55/month and is comparable to digital ocean's $18/month.
Unrelated, but this blog is difficult to read for a few reasons: bold black text highlighted with a gray background is too intense, line height is too small if they insist on using the highlighting, fully justified text for no reason.
Also, the navbar at the top of the page might as well be invisible.
To be fair, the author uses the qualifier "may" and explains the desire for monospace and consistency. It's not like it's clickbait, the author makes a valid argument. Perhaps disregard sub-headings if it results in overlooking the nuance of the article's overall suggestions.
Except monospace fonts shouldn't be used for prose, so the author is actively making the reading experience worse for... aesthetics and vanity reasons?
It's hard to respect the advice of a designer whose deviations from their own rules make the design worse.
Almost any web-safe font[1] would have been a better choice.
Resoundingly, the first. The second one is full of huge tiles that take up so much screen real estate, it's hard for me to scan over what is available. Crammed at the bottom are a ton of links, in no particular organization that was immediately apparent. The entire site is plastered with huge images everywhere, that don't really add to the content and just distract from whatever it was I was theoretically there for, and really don't help me understand the site at all. Also, the zoom effect on tiles keeps grabbing my attention when I was really just trying to move my mouse across them to get to something else that I'm now distracted from.
> * Nicer to to look at?
Depends on what you mean I guess; if you came to soak up pictures of smiling faces, I guess the second. But personally, I don't dislike the first.
> We don't live in a HTML only world because no one wants to live in a HTML only world. Some techies might but 99% of ordinary people do not.
I'm afraid this is a really awkward statement. There's no way to argue against it or really say anything to the contrary. You've framed it such that anyone who disagrees with you is "a techie" who in your definition does not represent any norm.
CSS could also solve this website's problem of a visitor reading the page title as "FABIEN SANGLARD'S WEBSITE ABOUT EMAIL RSS DONATE" … I thought it was a website about email and RSS and donations for a second.
This is another post illuminating the new minimalist trend in website design. The old minimalism was about "elegance", but this new trend is more about utility: we don't need CSS, just content, so why bother! I don't like this utilitarian take. It's fun to design a website.
Pretty sure it only comes from engineers. Not sure it’s a new trend.
I appreciate it personally. I think most styling is about UX and not communicating information (although it can improve that). But I think it’s at least jaded and probably even a terrible idea to suggest websites should generally be implemented this way.
I genuinely believe a site can be extremely minimal without sacrificing the visual component. But I also believe some people are pushing the visual part way too far to the point where sites are genuinely hard and frustrating to use.
327 comments
[ 3.1 ms ] story [ 238 ms ] threadThat combo is more than enough for almost all the websites out there, I've 3 different sites like that and they are blazingly fast, everything served from a $4 VPS (serving about 20k views per week).
[0]: https://en.wikipedia.org/wiki/Server_Side_Includes
[0]: caddyserver.com
I guess you mean because SSI is just a very limited mechanism as opposed to full blown Turing complete PHP or similar. But actually if the fragments/partials you include via SSI are user-posted content (comments) or syndicated content then of course SSI can't fence against <script> or other injections. In that case, you could use more sophisticated SGML mechanisms (other than SGML processing instructions as used by PHP or magic SGML comments as used by SSI) such as entity reference expansion that come with full type checking and context-dependent validity assessment for filtering all kind of injections (script elements, event handler attributes, image or link href injections or whatever). But you should at least use content-security-policy headers to block inline script.
If you stick to text files, you'll never have to go to caniuse.com ever. Need styles? Just make a PDF and throw that online. During the "XML HTML" phase the web went through, I never had to worry about validating my PDFs through an XML validator. Then when everyone decided using "<b>" and "<font>" tags was bad and insisting we switch to using "font-weight" CSS in a completely unrelated part of the file, guess what I had to do? Nothing! My PDF keeps rendering exactly the same way through every silly "trend" and "update" on the web, and never misses a beat on Lighthouse in Chrome.
Now if I could just convince all the browsers to implement .docx renderers out of the box, I'd really be set.
Just use some old chars (maybe them? https://en.wikipedia.org/wiki/Symbols_for_Legacy_Computing) and some spaces and boom, a nice style in a simple txt file!
This only matters if you actually care about exactly how your website renders on any given browser. Most websites don't have any need to care. PDFs are the worst for this: They care, A LOT. Which means locking you in to some hideous rectangle that's a different aspect ratio than any monitors I own, locking down the fonts and colors so that I can't just rely on system defaults, etc.
If all you need is to convey text, and maybe take some input, HTML is a fantastic solution.
I find it so sad that our browsers have such bad default fonts that all websites feel the need to override them to get an acceptable look. It would be great if browsers had decent defaults for both the overall default as well as serf, sans-serif and monospace so that most websites who aren't worried about font branding can just stick with the default and users can get a good fond, or even their preferred font if they bothered to customize it.
I don't mind Consolas, and I like what is author using now (DejaVu Sans Mono), but their stance about varying reading experience depending on the OS makes me really, really devastated, because it just reflects a sad state of IT literacy and general adoption of basic philosophy of the web, which was built on premise that how content looks like depends both on author and user (through user agent) and fact that generic font family looks ugly is in other words defaults are bad combined with users have a bad taste and set bad default values.
As was said, we are supposed to express our preferences in (through) our (user) agent's preferences.
Most probably your browser will use four distinct fonts on this page, *all* of them (and more) you can define in your browser's or operating system's settings:
It's sad that it is not a general knowledge.Authors defining background colour without defining text colour is the reason we cannot effectively have default dark background and light text default in our UAs, because in this case we would see authors (light) background and ours (light) text.
But yes, I have seen decent browser fonts for most Linux distros.
Newer releases also have San Francisco Mono that it could use instead, which is even better since it's tuned for modern displays.
Though of course there are plenty of discontents with that. On balance I think the apps that ship with MacOS are much worse than their Windows counterparts. I think iOS on the iPad is truly superior but the settings app is dark pattern city, particularly the notification that never goes away about the Apple TV trial that is about to expire but actually expired years ago.
Even having some defined meta fonts with rough metrics so that you could say font-face: monospace-standard or whatever and have the text be roughly the same size everywhere would save so much effort and wasted data.
Including a small set of open fonts does seem like a good idea. I'd like to see Inter UI[0] included because it's a very nice screen/UI-optimized font would serve a similar purpose as "system-ui" does now, except without some of the pitfalls[1] that comes with.
[0]: https://rsms.me/inter/ [1]: https://infinnie.github.io/blog/2017/systemui.html
I fucking can't stand Consolas, give me Courier New because that font is readable literally anywhere.
Courier New is the most appalling piece of shit I've ever seen in my life. It's ugly at small sizes, jagged and unpleasant at medium sizes, and abhorrent at display sizes. WOW do I hate Courier. I hate it on Git Bash. I hate it in cmd, I hate that it exists. Consolas, by contrast, is lovely and beautifully-hinted at best, and inoffensive at worst.
But no browser defaults to Courier New any more—Firefox on Windows was the last browser to finally update to a better font, just under a year ago (see https://bugzilla.mozilla.org/show_bug.cgi?id=1607913).
Felt. I actually do adjust my user agent fonts and system fonts, and I hate it when these "system UI font stacks" aren't just "sans-serif" and I end up with Arial or Ubuntu because some guru said this is how you do it. Especially irksome though is the monospace fonts--either Courier New (which hints way too thin to be readable on my main display) or using some hard-to-decipher custom font that abuses ligatures.
It could be kerning, leading, default font size, all come together in very powerful ways before finding a very specific font to enhance the brand experience.
If we look at HN, the window we type a comment into continues to use a font when writing that can help induce more awareness of writing. Maybe it would be slightly different if it was a blinking square cursor. Or a slightly taller box.
On my site for example, I designed everything using Iowan as my main font because I know that it’s available on most Apple OS but then I manually picked a few fallback fonts that should be available on Windows, Android and the rest.
Default serif is just the last option if everything else doesn’t work.
I'll happily lump JavaScript in as a major accessibility concern. JS is most often used where it shouldn't (most recent in memory is the Unreal Engine docs). Using JS for such simple presentations is like building a 5000-story building to print a sheet of paper, when all you needed was the pre-printed sheet of paper (HTML, CSS).
There's no reason websites should even be able to set the font in my browser.
If it was just about websites achieving an acceptable look, you'd see people emulating industry leaders, but that's not what you see. Google, for example, uses Arial on its main page on my browsers at least--that's a font that's available on every browser I know of. If it's acceptable for Google, it seems like it's just acceptable in general.
Instead, the fonts being loaded are about websites achieving their own brand. I've built a lot of web frontends, and every time I get a rebrand contract, the designs I get contain a bunch of fonts.
As a user, I don't give a fuck about your brand. Being able to read your fonts clearly is a much higher priority for me than experiencing your brand. Fundamentally there's no reason at all that sites should be able to decide for me what font I read. I am lucky to have fairly good eyesight and no serious processing disorders, but users who have these issues are seriously negatively effected by sites overriding their browser defaults. And since few projects are given adequate accessibility budget, users are left with no recourse. Overriding a website's fonts with your browser settings doesn't really help, because sites often use pixels and other dimension units that make your site unreadable if you use a different font than what they tested with.
Of course that can also be fixed, but there's only so far you can take this. I have the technical ability to edit CSS, but I don't reasonably have the time to do it for every site I visit.
I tried this as a two-week experiment a year ago. I’ve never gone back, it improves the web so much.
(Well, actually I also block web font downloading altogether, for no particularly good reason, at the cost of icon fonts and Material Icons breakage, but it doesn’t often matter.)
Both do use icon fonts for some of their additional controls on the right hand side, but they all have tooltips so that you can identify them even without the icons. Chess.com uses a bad icon font that uses non-PUA code points (e.g. V = New Game, , = Move Back, … = Move Forward, g = Show Hint), so those ones will be broken. lichess.org uses PUA code points (except for “½” for “Offer draw”), so I think that those icons would even be loaded if you weren’t like me in just blocking web fonts outright.
It quickly gets more complicated for some sites, which users might use often. There are folks talking about how you can use custom CSS to fix just about any site, and that's true, but how technical are we expecting users to be?
And even as a user who develops websites for a living and can definitely do all this, I don't want to. The web should be designed to work for users by default. I shouldn't have to fix websites to use them.
Come now, it doesn’t take any technical ability to use the checkbox. It’s called “Advanced” because it’s more complex tweaks that most people aren’t interested in and which take a moderate amount of space so they want to keep it out of the way lest the page get too long, not because it’s hard to use in any way.
> It quickly gets more complicated for some sites, which users might use often.
It is rare for this to have any ill effect on any site (icon fonts that don’t use the PUA and aren’t Material Icons (for which Firefox has manual exceptions in place) are about the only case, and they’re distinctly rare nowadays—I only recall encountering about two cases last year, both of which were paired with labels and thus unimportant), and in those rare cases it’s unusual for it to be a real problem (they’ll almost always have labels or tooltips).
I will quite happily recommend changing this setting to completely untechnical users. It occasionally causes very mild harm, and can theoretically cause great harm for particular sites (but I haven’t found such a site for years, and any such sites were surely already broken anyway), but the rest of the time it improves matters markedly.
It's clear that you don't interact with average users very often if you think this.
Obviously you can direct the user through to the steps to check/uncheck a textbox, but understanding what that checkbox actually does and why they might want to check/uncheck it is far beyond the technical understanding of most users.
He talks about the evolution of his blog in this post[1] and has a link to the web archive of an early version.
[1] https://fabiensanglard.net/ilike/index.html
I think articles that are just all about how you're bothering your readers can be a bit tedious, but there are ways even the owners are hurt by the belief they need every whizbang thing, because they all have maintenance costs and general quirkiness costs associated with them too.
Now wasn't that easy?
One problem not listed is source code syntax highlighting. If you provide source code listings in articles, then highlighting is a big help to readers. Generating it in HTML is not fun.
All your blogs need is HTML.
> But mostly css appeals to our vanity and ego.
Design isn't just about aesthetics. Good information design, clear visual hierarchy, accessibility, etc. all help with communication. The author's effective use of spacing, bold, and code tags show us that they know this intuitively, despite what they write.
Hell, that typeface is something anyone is subjected too if you do anything long enough.
The experience of getting to imagine how much thought goes into laying out text on a typewriter is something I think should be for everyone to try at least a few times.
And as mentioned, I achieve it myself with a style extension.
Isn't that what HTML gives us?
I'd say HTML for itself just gives us a way to give meaning or imply how something should be styled "headline of first order". In the end it's a markup language, not some magic styling tool.
How it is actually styled (in absence of CSS) is in the hands of the default rendering of your browser. That might very well be a very bad rendering, due to lack of knowledge/time/engagement of the people building/maintaining that renderer.
Also those renderes might come from a time and system where technical limitations where different, markup was different, lots of things were very different.
So I don't think we should expect HTML alone to "look nice" or work well in regards of readability.
I think we would win a lot if browsers default styles were beautiful (as in: really good, not merely fancy) designed. Many websites then would need just a few lines to set some colors, style that weird-custom thing they do or make it feel just a bit more personal.
If HTML were truly semantic, browsers could implement accessibility features around it, but because they're so vague, there's no real way for browsers to do that, which offloads the responsibility onto web developers, who in most cases aren't granted budget to do it. There are a handful of features such as alt properties, but these are pretty limited.
So yeah, HTML should give us that, but that's part of what users gave up when we decided it was acceptable to allow random websites to run code on our machines and tell us how our content should be displayed.
All the HTML5 input types are also an example of semantics impriving. It could be way better, but it's not a total stalemate
How does this differ from how <div> was being used before?
I've switched to using <section> simply because it's a better name, but I'm not sure it's made any meaningful difference in my code.
Another example of the pointlessness of this issue is <em> and <strong>. I've rarely seen code where these weren't used exactly the same as <i> and <b> were before. In rare cases, I've seen someone do something like make <em> a different color rather than italic, and that's almost always been a bad idea, because when HTML authors use <em> they almost always intend for it to be italic. In fact, I'd say we should just continue using <i> and <b> because those communicate intent better, but at this point I've worked in too many codebases that decided that <i> could be hacked to mean "icon" (i.e. using FontAwesome) which is a horrible, awful, no-good, bad, hack.
> All the HTML5 input types are also an example of semantics impriving. It could be way better, but it's not a total stalemate
That's true, but I think we'd be moving forward a lot more quickly if we weren't devoting most of standards development resources toward giving companies more fine-grained control of our browsers through CSS/JS.
There was never a golden era like you describe (it was a time of conflicting philosophies, people saying "eh, let's add this, that would be sweet", and browser vendors competing to add as much as possible to out "innovate" each other and the limited specs), semantic HTML helps in some cases but is never going to give you automatic accessibility, and a one size fits all browser style is still not going to give you what you need even as you add increasingly unsemantic tags to try to improve it (which is exactly what was happening pre-CSS).
I've been writing web code since 1997ish, so...
> There was never a golden era like you describe (it was a time of conflicting philosophies, people saying "eh, let's add this, that would be sweet", and browser vendors competing to add as much as possible to out "innovate" each other and the limited specs)
I did not describe a golden era of HTML, because a golden era of HTML never happened. Instead, it was precluded by the introduction of JS/CSS. Had JS and CSS never been invented, we might have achieved a golden era of HTML, but we would have needed web standards to mature before that could happen. What happened was, web standards did mature, but they matured to serve websites rather than users. As a result, mature web standards center around JS and CSS, leaving HTML anemic and weak.
What we have now is a time of conflicting philosophies, with websites competing to add as much as possible to out "innovate" each other. Users still suffer the same inconsistent interfaces they did in 1997, it's just that instead of browsers being inconsistent, it's websites that are inconsistent.
Hell, the entire reason the internet moved from Holy Grail layouts to singular sidebar and vertically integrated layouts was because CSS can't into Holy Grail.
With how wide most users' monitors are ever since 16:9 became commonplace, Holy Grail should be the ideal content presentation layout because it uses all that free space on the sides for non-content (eg: navigation) so precious vertical real estate can be dedicated to content.
HCI dictates how humans use interfaces and with that comes many defacto reasons why a plain text page does not solve the problems users want to solve. Do you not think websites test into the optimal performing layouts and content distribution? If it worked better, we'd all be using it (it doesn't).
No, I think most website devs left to their devices optimize for least effort to create and maintain.
...which is definitely not tables. Flexbox is much easier.
But the key, underlying point to ALL this stuff is that you do NOT NEED TO WORRY ABOUT PRESENTATION until you have the CONTENT.
A huge temptation is to spend hours and hours tweaking the presentation as a way of avoiding actually creating the content; this is the real danger.
(should mention https://thebestmotherfucking.website of course)
The balance between design & function can be at odds when the mission of the page is not clear.
For consumption, these are awesome, your brain almost relaxes as it's easier than the usual onslaught.
The CSS of the second website is wrong, as it uses 'color' without setting 'background-color'. Assuming anything about the default background color is not possible because it is user-configurable in most browsers.
At least http://motherfuckingwebsite.com remains readable when you change your color settings (the second one is completely unreadable on my browser).
The text was readable as designed on a white-background. CSS that considers accessibility or print friendly is always good to add.
Javascript test?
If it was a javascript that checked for the elements you want to ensure is there that would be neat too, I just wouldn't want it to be just me :)
I can't speak for other frameworks but tailwind only compiles the classes you actually use at build.
If the whole point of your website is to brag about code to accomplish reasonable formatting.... can we at least have code formatting? I think I have enough bandwidth to afford some line breaks.
Client side GA????
So, to extend your comment: you do not need to worry about content if your website isn't even reachable. A GET request should never result in the client being bombarded with captchas. Unless you have a sure fire way to determine if said client is a human or an evil AI taking over the world (nobody does), just serve the damn page.
It's definitely not, there is something else doing that to you. But it's not this website.
same went for emacs I stopped using themes
Mailing lists are still good for that I guess.
Bold statement. Those look mostly terrible to me.
Such drastic difference with basic adjustments, damn
I flipped over into reader mode and it's much improved, solely because of line length and dark mode.
Initiate rant mode:
- The gray on gray is like a joke, except it's not. I get the theory and alleged benefits. I get that some do prefer it, especially for IDEs. I get that some are happy to see (or at least apply) it all over the web. It just does not seem to apply here. Man alive. Literally making it harder to differentiate the text.
- I don't mind adjusting the browser width to get the lines exactly the right length for my screen and reading preference. Actually, I far prefer it over all the other options. This is like a tragedy-of-the-commons or lowest-common-denominator or dumbing-down-on-the-false-premise-of-being-smart issue. Instead of utilizing what we have, and encouraging people to learn and become capable with the simple and flexible tools, it's one size fits all (or, you pick the size you think I want). Only it's not.
End of rant. Sheesh.
On the other hand, I was disappointed to see the unique one of those I think it is worth to follow the advice [1] was not cited.
For curiosity reasons, I found out about [1] on a well-known website [2] that definitely puts content in front of presentation, even though I like their website's design.
[1]: https://bestmotherfucking.website/
[2]: https://suckless.org/sucks/web/
Of all of them, I think the one you linked is probably the best. It is still interesting to watch the progression.
An UI made of disintegrated, inconsistent and half-assed tries at writing CSS/JS. Not a rare problem in my experience.
Also happens to me when trying to write a "tiny web app for fun" where the CONTENT is interactive and created by myself.
[0] example post from my blog https://mvexel.prose.sh/20230227-keeping-osm-database-uptoda...
Everybody finds their writing juices differently. Push where it means you'll write more.
Javascript transitions/animations, on the other hand... yeah. I won't got there.
But alas, base styles are a mess (yet still there!). They do have some hierarchy but accessibility and readability are bad. That's aside from aesthetics: just stuff like alignment, spacing, fonts, flow: very poor.
I am aware that more base styles would make that cursed "reset.css" even larger, but I guess if a large part wouldn't even need that, it would be fine. It would be a situation where everyone can choose "good styles" or "spend lots of effort to get even better, custom, styling", rather than everyone "spend lots of effort to get an even decent styling".
Keep it all the same as current if there's no tag on the page, but if you add something like <meta uastyles="1.0.0"> or something, apply an improved set of default styles.
Get rid of the need for resets with <meta uastyles="none">
Basically - I'd love a way to allow browser vendors to dramatically improve the defaults without breaking everything, and also giving frameworks an easy opt out.
There's nothing here that would stop you from still doing that.
But if we're talking about practicality... I think far more people would get a benefit from improved defaults (as long as they're not breaking existing sites).
While I've modified the user styles for my chrome profile as a part of being a web developer, I'm not aware of a single non-developer acquaintance who has (literally - none). Honestly, not even many of the devs I've worked with have done it.
It's just not all that relevant when the defaults are so bad that all the sites are overriding them anyways. Makes it very hard to apply a set of user styles that's sane, so no one does.
Make the defaults better, and maybe you can end up back there.
My browsing experience should not be determined by an artist or product designer 1000 miles away from me in an office somewhere.
My language skills and time pressure fails me here, just wanted to express general "thanks folks" for your reactions as well. Seeing that someone shares similar point of view on this topic made me surprisingly very happy, so thank you again.
Visual communication and design predates CSS. Information architecture, design, guiding the user through the message is definitely a skill.
CSS can do as much distraction as it can enhancement. It's one appeal of Tailwind, it's more than serviceable while learning about the design, hierarchy, and flow.
That can mean going all out in design, or having an HTML-only page like nothing. Both have value in their own way, and should reflect the creator to some extent.
Message / medium have always mixed together.
Even folks who say content needs to be figured out before presentation... it's not so cut and dry. Your medium shapes your message - they are not mutually exclusive and for the receiver of the message, the medium matters for their reception of the message.
I understand the sentiment that TONS of CSS is probably a bad use of time. But trying to demonize or otherwise attach aesthetics the label of "meaningless" is, in my opinion, just as much egocentric as they claim CSS to be.
> scroll the mousewheel: giant footer section slides up taking half the viewport
> move the mouse cursor up: giant ass header slide menu drops down covering half the viewport
should be absolutely no motion on a page unless i specifically click on something, like play button or slide out button. and that includes parallax bullshit.
prefers-reduced-motion should be the DEFAULT not an override. ffs haven't we learnt anything in the last 20 years of web dev - you cant rely on web monkeys to build things right (\s).
---
and f*k you to whoever thought having mouse hover popup autoplay boxes on youtube was a good idea.
I don’t personally feel nearly as strongly about the subject, but I wholeheartedly agree with this.
You need a UI team to create a page of readable text? That sounds like an expensive waste.
But it sounds like those 'UI' people think they know better and don't need suggestions from programmers about reading words, even though its what they do all day.
Books are designed, too.
And I don't know where you've been for the last 30 some years, but the web is not a text only format, and the reason HTML was invented was specifically to be able to create a designed space where text can actually make sense and is not a gigantic wall of impossibly small black on white text.
Yet the market for text only novels is staggering.
While you do have some going to that extreme, I think it's mostly pushback against the insane amount of bloat and overbusy design out there. Some CSS can be useful, to improve readability and offer a little visual appeal. But I think maybe you missed my point.
Traditional books are typeset the way they are for a reason. No or minimal pictures. Block after block of text, broken up and spaced for readability, comprehensibility, and flow. Different types of books are laid out differently, but they mostly follow this theme. It's highly effective.
You kind of broadly have 3* categories of web pages on the web, as relates back to print:
* Book-types (mostly text in nature) * Magazine-types (more about graphic design, with content mixed in) * Advertisement flyer-types (sales pitches, mostly about design)
These are going to have different design requirements. There's plenty to write on the subject of design for these categories, but in the interest of getting to the point: there's an awful lot of the first category on the internet, and it really requires very little in the way of CSS. It certainly doesn't require hero images and 10MB of javascript. Blogs should read like newspaper articles, technical content should be typeset with similar minimalism to technical papers or books.
* There's a fourth category: webapps. My personal stance is that these don't belong on the web at all, but given that they're going to be, they obviously have far different design requirements, and are quite outside the scope of this discussion.
Feel free to find a site better than http://motherfuckingwebsite.com/
Like I can barely imagine what your house might look like. Just like a purely functional weathered hovel with the absolutely barest essentials. A perfect prison cell
Why dismiss aesthetics out of hand like this, equating it with vanity and ego? Aesthetics are very important to people, possibly even more so than the information on the page.
That's not what I think the www is for, but not everyone agrees with me.
Then it shouldn't exist from the start.
> Custom fonts are a waste of bandwidth
Latin subsetted fonts are generally 10-30Kb, it's really not that much. For comparison, it's unlikely you'll see blog authors get up in arms over a single PNG.
> they come with one of three evils called latency, FOUT, and FOIT
A few milliseconds of a different font appearing is truly not much of an evil, but can be addressed by exactly what the author links in their footnote.
Humorously, the author's own site is committing some sins here: both of two font files are >140kb, they don't have gzip on, and they have the fonts marked `font-display: block`. They could cut their CLS and LCP by almost 100% by addressing this: https://i.imgur.com/MOl32iS.png
Of course, it's already very fast, by virtue of having no other resources loading. This would be dramatically worse if there were scripts that needed to get downloaded.
Agreed. Make your own custom font files with only the characters you use, or are likely to use.
> A few milliseconds of a different font appearing is truly not much of an evil, but can be addressed by exactly what the author links in their footnote.
Browsers will wait for about 3 seconds for custom fonts to load before showing a fallback font.
> both of two font files are >140kb, they don't have gzip on
woff2 format fonts are already compressed, so gzip won't do much.
Depends on the `font-display` value on one's `@font-face`, which is where the author's choices of "latency, FOUT, and FOIT" comes from. For instance, Google Fonts uses `swap` by default, meaning the fallback shows right away: https://web.dev/font-best-practices/#choose-an-appropriate-f... (I also think Safari's `auto` font-display never shows fallbacks, but that may have changed)
But if you use `optional`, browsers will attempt to get the custom font into the first paint: https://drafts.csswg.org/css-fonts-4/#valdef-font-face-font-...
That's often enough. You can go another step further and preload the font, which I generally recommend. This especially helps if the font is otherwise discovered late by the browser.
Please, eat your own dog food first.
> A DNS pointing to the host Hostgator for an extra $12.95/year.
Why not use Netlify or GitHub pages? They can host static files for free.
I host a bunch of files and static html on my domain and I’ve moved it to github pages. The dns services bundled with the domain at gandi are enough to set it up on top of the free github pages, so my hosting is effectively free, and if I wanted I could still run a site generator.
Static html gets even easier by using something like simplecss, because that gives a basic design with zero effort on top of semantic html. https://simplecss.org/
This is blatantly incorrect or a flagrant misrepresentation. CSS can certainly improve readability without adding design.
Readability is a check list which stock HTML does not address.
https://practicaltypography.com/
On the main blog page, it sure looks like some of the entries are not sorted properly. For example the 10 Feb 2020 ThinkPad review.
Oh wait a second. Some of the dates are DD/MM/YYYY and some are MM/DD/YYYY!
If you need any sort of "stack" to fix the problem of "my dates are inconsistent", you're in serious trouble, my friend.
I always find static site generators a kind of leaky abstraction. They eventually try to abstract nearly the whole functionality of the web stack, and the larger the SSG the more apparent it becomes. But, for obvious reasons, they just cannot abstract all the peculiarities of the web from you.
I write posts in Markdown, use Pandoc to convert `.md` to `.html` and a simple Go script in 200-300 LoC [1] for my https://hirrolot.github.io/.
[1] https://github.com/Hirrolot/hirrolot.github.io/blob/master/g...
Firebase Hosting in particular is really easy to get started and connect a domain to it. The Firebase CLI tooling makes it dead simple to deploy updates as well.
But, really, in my dream world, ISPs would also act as registrars for their clients, so, once you pay them you get some automatic domain name, or maybe can pay a bit extra for a permanent one that you can take to the next ISP you sing with.
At the risk of being pendantic, asmallorange and hostgator are owned by the same entity[0].
That said, I like the premise of just writing and producing content and not necessarily worrying about setting up tooling. I think devs, and "geeks" in general, tend to enjoy tinkering with tooling, but it can be daunting for the less tech savvy. I suppose that's why things like Wordpress.com exist.
[0]: https://en.wikipedia.org/wiki/Endurance_International_Group
The more I learn, the more features look like training wheels and training wheels like restraints.
Their VPS offering is $55/month and is comparable to digital ocean's $18/month.
Also, the navbar at the top of the page might as well be invisible.
> The fluff does not really matter much.
> WHY YOU MAY NOT NEED CUSTOM FONTS
> Custom fonts are a waste of bandwidth and a visual annoyance
Right-click -> View Page Source. Top of the page is a stylesheet that loads 2 fonts. Hard to take this article seriously.
It's hard to respect the advice of a designer whose deviations from their own rules make the design worse.
Almost any web-safe font[1] would have been a better choice.
[1]https://www.awayback.com/index.php/2010/02/03/revised-font-s...
http://www.columbia.edu/~fdc/sample.html
https://www.columbia.edu
Which one is: * Easier to navigate?
* Nicer to to look at?
We don't live in a HTML only world because no one wants to live in a HTML only world. Some techies might but 99% of ordinary people do not.
No one wants to look at black and white text all day, with every website looking exactly the same.
If this is what people wanted, then you'd see a lot more of these plain HTML websites. But you don't.
Resoundingly, the first. The second one is full of huge tiles that take up so much screen real estate, it's hard for me to scan over what is available. Crammed at the bottom are a ton of links, in no particular organization that was immediately apparent. The entire site is plastered with huge images everywhere, that don't really add to the content and just distract from whatever it was I was theoretically there for, and really don't help me understand the site at all. Also, the zoom effect on tiles keeps grabbing my attention when I was really just trying to move my mouse across them to get to something else that I'm now distracted from.
> * Nicer to to look at?
Depends on what you mean I guess; if you came to soak up pictures of smiling faces, I guess the second. But personally, I don't dislike the first.
> We don't live in a HTML only world because no one wants to live in a HTML only world. Some techies might but 99% of ordinary people do not.
I'm afraid this is a really awkward statement. There's no way to argue against it or really say anything to the contrary. You've framed it such that anyone who disagrees with you is "a techie" who in your definition does not represent any norm.
I appreciate it personally. I think most styling is about UX and not communicating information (although it can improve that). But I think it’s at least jaded and probably even a terrible idea to suggest websites should generally be implemented this way.