Maybe it's just me, but I'm not so much of a fan of Dialogs as demonstrated here, especially when there are a lot of characters, each of which have a different role that is only communicated by going to a separate page to read about them. If I wanted to explain something in an article I was writing, I would just explain it in the same way I'd do everything else, with a separate paragraph, maybe with some links to relevant sources that I used to become familiar with the topic too
It takes a lot of skill on the part of the author - I don't think I'd risk it personally.
But I like the way it's handled on fasterthanli.me enormously - the author there successfully anticipates a lot of my "wait, but..." thoughts and addresses them directly via this mechanism, or, conversely, makes me realise that I ought to have had an objection to the point they're making.
I've just read a couple of their articles, and I think an aside works nicely, just a note about something, but a full on dialog is a bit much. I suppose a lot of my concern was with how Xe Iaso does it, where it just feels over the top and unnecessary, and IMO distracts from the actual content of the article, which is otherwise largely enjoyable
It is a very hard thing to calibrate. I try to have my internal conflicts and the like get put onto the canvas. I imagine that part of the perceived distraction is because of the CSS being bad (I suck at CSS so much). I'll go dig through a few Tailwind examples and see if I can make the messages more compact.
Well I didn't expect you to actually read this haha. I hope I didn't cause any offence, I just struggle to keep your wide character roster in my head with all their specialised roles. The only reason I mentioned you specifically was because I was familiar with you as an example and the source mentioned you, I'm sure others do this to an even larger extent
Yeah, I try to compensate for this with a few rules that I undoubtedly fuck up:
* Each character has very visually distinct designs (ideally each is as distinct as I can reasonably make them, to the point where I have different artists do each one)
* The names have meaning (Aoi means blue, Aoi's hair is blue)
* Each character has an archetype that corresponds to a facet of how I understand technology, and their interactions are intended to reflect those internal disagreements or touch on the intentionally placed "learning lies" (the simplifications of how things work intended to give people a starting point for understanding an abstract thing that can later be discarded when they dig into the details and realize that shit's actually complicated)
I've been idly considering adding something to the message footer in faint text with a tl;dr like "(the student)" for Aoi, or "(the well-intentioned forum troll)" for Numa. Would that help?
I originally was kinda hesitant to do this under the axiom that if you have to explain your art, you fucked it up. I'm willing to concede that it's probably a bad axiom for me to follow here.
I was going to suggest having hover text for the characters that just summarises what you already have in the separate bios page, but I've just remembered that doesn't work on mobile haha. Adding faint text might help, though you have to keep accessibility contrast guidelines in mind :P Ultimately, this is just my viewpoint, and your website, so you should do what you feel is best haha
I'd always thought that inline dialogs with fictional characters were more for the author's entertainment than the reader's, so I was surprised OP and others in the thread like them.
I have nothing against them if people like them; just a matter of taste.
Dialogs are definitely an interesting form of writing, especially for technical writing. On the one hand, it's a deeply natural format with a long and complex history (the Socratic Method, especially, but certainly not alone). On the other hand, we've long disassociated it from "professional writing" which is to supposed to only have one proscribed argument and one direct viewpoint (likely, but not always, the author's).
Somewhere in the middle, is decades of the "…for Dummies" technical manual formula and its stock dialog characters and the love affair many had (or still have) with "The Poignant Guide to Ruby".
Dialogs can definitely be hard to read in the context of just reading a single blog post because you don't have a familiarity with that author's characters and most blog authors don't have a "shared universe" of characters. I wonder if there's an interesting world where for instance the Dummies characters were considered to be public domain at the right time or more blog writers felt confident with _why's unique voices to turn Poignant's characters into a modern "Punch & Judy" for technical writing. The Socratic Method worked because everyone had a shared intuition on the characters of the day (in part because many were famous Senators and/or Wrestlers): Plato, Socrates, Aristotle, etc. (Also, Plato was his wrestling name, these were absolutely characters.) Maybe if we want to use more Dialogs in blog posts easily we need better shared characters?
Agreed. I can rarely identify with the character(s) I’m supposed to identify with, and it’s virtually always a tedious read.
It’s also possible to use a question-answer style without having a dialog and characters. What would that look like? Well, similar to this very paragraph. Not that I would particularly recommend it either.
Printing CSS doesn't get enough love. The ability to easily create a PDF for later, or to simply print the blog post on a piece of paper to read it outdoors is something I value.
Also, I'm confused about some points. For example, is progress meter really necessary? I mean, isn't the scrollbar a good indicator for the progress?
A progress meter may not be necessary, but as the article points out if you have comments or an otherwise large footer not associated with the content of the post, the scrollbar can be deceiving.
I'm personally a huge fan of the progress meter (having once thought it was redundant as well) - one other easy addition I didn't see mentioned is an "estimated reading time." Having a ballpark range for how long I should expect to spend with a piece of content greatly increases my chance of engaging with it, and the progress meter creates a tangible representation of that time (and how much of it I have left to finish consuming the content).
I'm not sure how "estimated reading time" works for non-english speakers.
As for "progress meter" being an optimization of websites with large footers or long lists of comments, I'd argue that a better optimization technique would be to remove the footer, or remove/hide by default list of comments (i.e. make it available with a mouse click somewhere).
> I'm not sure how "estimated reading time" works for non-english speakers.
>
Do you mean for non-native speakers reading English material or for material in other languages when read by native speakers with an average reading competence in their native language?
Anyhow, as a non-native English speaker, it implemented it on my site by showing both the word count, as well as an estimated time, which is simply calculated by dividing the word count by a constant number of assumed words per minute.
That number was guesstimated by doing some reading speed tests on myself and researching average reading speeds and rounding up to 10 wpm. I have to admit that my assumption of 240 words per minute does not hold up to any scientific scrutiny, but otoh it is an estimation.
It works ok for prose. As soon as other notation is mixed in (code, math, graphs, diagrams etc.pp) that begins to naturally to vary wildly in accuracy.
>I'm not sure how "estimated reading time" works for non-english speakers.
Do you mean people whose native language is not English? I assume it works the same way as for everyone else, i.e. it's always an approximation anyway. I'm not from an English-speaking country, but I'm pretty sure I read faster than the average English native.
The other interpretation is that you mean people who can't read English at all, but in this case I understand even less. They won't be able to read the article, if they don't speak the language. After automated translation, the reading time should be roughly correct again.
in the early days of blogs, i found comments to be interesting and engaging dialogs. the last decade, or so, i’ve found comments to be unhelpful nitpicking/personal disagreements, spam, or support requests, so i’ve completely stopped concerning myself with comments on blogs.
so i’ll agree that progress indicators are helpful for this use case.
The scrollbar is not reliable. On Apple platforms, they hide the scrollbar unless you’re scrolling. I think CSS lets us specify that it should be visible on our own pages, but I don’t know how that interacts through browsers to the native behavior.
> (btw, just checked for Firefox and Safari, and the scrollbar is visible at all times, unless the website explicitly hides it)
There is a setting for this called "Always show scrollbars" and I know it defaults to off for me. The underlying about:config rule is specific to GTK though, so this may be platform-specific.
I was checking this on macOS. I have system scrollbar setting set to "automatic". Never changed scrollbar settings in Safari/Firefox, so it works like this for me by default, not sure why.
But also I don't really get how people are fine with hiding the scrollbar, but prefering to see the progress meter always visible for text, when the scrollbar conveys mostly the same information (except some edge cases when the footer is long I guess).
Not that it's important at all, I'm just at loss and it's not the first time I'm getting a signal that sometimes I simply don't understand people. But of course that's fine.
The scrollbar is per-page, the meter is per-article. Lots of blogs where I see a progress meter also have multiple articles on one page, sometimes even infinite scroll. I personally find the meters kind of superfluous, but they don't bother me since they usually stay out of the way.
Oh this is a great list. Thank you. A few things on here that I'm now going to spend the day bringing to my site. I like how you explicitly called out a few things Gwern does. I love that site but hadn't examined closely _why_.
Here is a few additional things not on your list that I love and have implemented on my blog:
- Plain text versions of all posts. Change the file extension on any page on my site from ".html" to ".txt" to view it as plain text (https://breckyunits.com/intelligence.txt). Makes it easy to copy/paste a whole post into an email or Reddit submission
- View source links at the bottom of every page. Every post is 1 file tracked by git, and I put a "View source" link at the bottom of each page. Even the static pages are also one file, and also have a View Source link.
- Keyboard nav. Use the left/right arrow keys to navigate through pages on my site.
- Helpful 404s. If you mistype a url, the 404 page compares it to working urls and shows you the closest match. All done using clientside JS (no web server needed). For example: https://breckyunits.com/pcr.html
- Download entire site and read offline. Everything is designed to work fine locally and you can download the whole thing as a zip. (The link is at the bottom of every page)
- Printable. Everything is designed to look decent printed. Nav elements are hidden via CSS when you go to print. I haven't added automatic generation of PDFS yet, but that is on my todo.
> - Keyboard nav. Use the left/right arrow keys to navigate through pages on my site.
Please don't, this is horrible and I've previously only seen it used by clickbait news sites.
It provides no real value, the only use case of somebody wanting to browse through just the start of each of your articles is going to be incredibly rare. But what you're doing is hijacking a key that normally has no effect into having a destructive one. All it takes is a minor keyboard fumble while trying to scroll, and you've just lost all context and confusingly taken to some totally unrelated article.
In theory is the same as in practice, in theory. But in practice, they're different.
> It provides no real value,
This is wrong. It provides a tremendous amount of value. Source: I use it many times a week, for many years, for many reasons.
> destructive one.
This is wrong. These pages are immutable with no state. If by chance you accidentally hit an arrow key on one of the rare long form pages with scroll, sure you lose about 50 milliseconds of time getting back to your prior scroll level. In years of doing this not a single person has ever complained, while instead a number have commented that they like it.
> In years of doing this not a single person has ever complained
I've never used your website, but if I did and the side arrow changed things, I'd immediately close it and never come back. You wouldn't get a complaint from me; you'd just lose me instantly and permanently.
It drives me absolutely nuts when sites do this, it is so disorienting.
> I'd immediately close it and never come back. You wouldn't get a complaint from me; you'd just lose me instantly and permanently.
Do you think this concerns me?
I don't make this site for you, someone who admits they've "never used" my site.
I make my site for my regular readers, some of whom have been reading the site for over 10 years.
The people who regularly email me comments and feedback on my posts. People who _love_ the fact that they can flip through the entire blog in seconds using the arrow keys.
> when sites do this
My site is not like other sites on the web. In fact, it is such an outlier, that I've recently started a new successor to the WWW, called the World Wide Scroll, to start aggregating more sites like mine.
My site is entirely public domain, has no advertising or trackers or cookies, can be downloaded in 1 click and used entirely offline, is written in a new language (Scroll) that is mathematically shown to be the simplest/most powerful language yet invented, that compiles to HTML/CSS/JSON/XML/RSS/plain text, is fully tracked by git so you can see the history of every line in every file.
> a new language (Scroll) that is mathematically shown to be the simplest/most powerful language yet invented
This is, at best, ambiguous. To show something mathematically, you have to have a precise definition of it, and neither "simple" nor "powerful" admits a precise definition that is widely agreeable enough for any mathematical proof based on it to be worth anything.
I was thinking about this recently as I added it to a site. The use case is slightly different because the site in question was more data-driven than a blog. One example is viewing an individual item and being able to navigate to the next item in alphabetical order. This uses link elements with the appropriate rel values.
The problem of losing context can be mitigated by having the page return to the previous location on back, something which browsers kinda already do, just not very well.
Alternatively, I assume you'd prefer some kind of modifier? This has problems of its own — e.g. shortcut clashes. YouTube uses comma and full stop as frame next/previous shortcuts — maybe we should standardise on those?
> - Helpful 404s. If you mistype a url, the 404 page compares it to working urls and shows you the closest match. All done using clientside JS (no web server needed). For example: https://breckyunits.com/pcr.html
I haven't found a nice way to do this on both desktop/mobile. What I want is for every heading to have an anchor link that can be copied, similar to a hyperlink. I see a lot of sites do this with a [unicode chain symbol] which is present on hover, but that's not an option on mobile. Alternate option is to have it next to every heading (ugly), turn every heading into a hyperlink without styling, or make them look like regular hyperlinks which I think is confusing.
Have an icon appear on hover, and make every heading a hyperlink (even without styling), and have a table of contents with links to each heading (with styling). No need to dumb down your interface just for smartphone users.
The anchor symbol can have JavaScript that copies the link to clipboard on click. And the heading can be a plain old link to itself. Gives a nice visual and interaction for desktop while providing a way for mobile users to get the link too (long-press the heading and copy link).
I don't think it looks that bad. My blog's anchors are hover-visible on desktop and always visible on mobile (with lower opacity). I used this query to check for hover event availability to decide whether they should be always-visible: `@media screen and (hover: none)`. I think it turned out pretty ok¹.
/* keep the icon hidden by default */
:is(h1, h2, h3, h4, h5, h6) .icon {
visibility: hidden;
}
/* show the icon on focus and hover */
:is(h1, h2, h3, h4, h5, h6):focus .icon,
:is(h1, h2, h3, h4, h5, h6):hover .icon {
visibility: visible;
}
/* show the icon on devices that don't have any accessory that can hover */
@media (pointer: coarse), (any-hover: none) {
:is(h1, h2, h3, h4, h5, h6) .icon {
visibility: visible;
}
}
The `pointer: coarse` media query checks if you are using a device with an input mechanism of limited accuracy (such as fingers on a touchscreen). The `any-hover: none` media query checks if none of the input mechanisms on your device support hover (such as a Surface tablet not attached with a keyboard).
I've been experimenting with encouraging rabbit holes within my notes by opening any note you click on under the current open note. That way you can investigate, collapse and close related things to what you are reading without having to leave the page or juggle tabs.
It's all based a static site and it relies on HTMX for this feature. I've also made sure the page works without JS. For now it is a bit rough and sometimes it may not be clear that it opened underneath but I want to explore this a bit more.
These features are all sage advice for any blog in my opinion, and this blog is a good example of one that is easy to follow as a result.
Regarding the Table of Contents feature, however, I believe this makes a big difference in larger blogs, but for medium sized or smaller blogs, it can be a distractor. I use Hugo as well for compositing my site, and find that using ample first level headings (e.g., # Heading name) for major components alongside a solid flow that contains visual graphics placed shortly after the heading offers an attractive and easy-to-navigate browsing experience.
> Regarding the Table of Contents feature, however, I believe this makes a big difference in larger blogs, but for medium sized or smaller blogs, it can be a distractor.
Ah. That resonates. Thank you for breaking it down like that. I've pondered adding ToC, but now realize it's only for a small subset of pages that it adds value, rather than distracts.
Tables of contents are tricky. My publishing logic is rather flexible in how I use them, so I used to put them into the margins of longer articles[1] and sometimes even shorter ones[2] although I wasn't great at always remembering to do it[3].
But the problem for me is that good headlines, that give a fair summary of the section they are for, make for really wide tables of contents which don't fit neatly into the margins[4], so sometimes the table of content has to occupy space in the main section[5] which seems to me like it distracts a bit from the actual content.
Doing a direct mapping from Markdown Headings to Table of contents+Anchors via Eleventy [1] is what I went with for my blog [2], simple setup, works perfectly.
I think Notion has nailed it with the new design of their table of contents [1]. The problem with the current general approach is that if a blog post is very long and you are in the middle of it, you might forget what the content was. However, having a very small item on the right that you can quickly peek at is awesome.
A ToC might be more distracting with a style that benefits less from a clear structure, like a personal essay. It can be important in a more technical-procedural style of writing, though.
Neat, although some of them are actually helpful for specific articles. One thing that I actually seen as a pattern is over engineering the blog so much that features need maintenance.
I don’t know if it’s a feature, but a summary/tldr/abstract at the top is imo better even than TOC. Not only are to-the-point abstracts amazing for the reader, but also for the writer. Oftentimes when you can’t summarize properly, it’s because the article isn’t focused and needs rework.
Centered for me at my usual browser width, then jumps to the left when widened to make room for the single side note example. A note that, boo hiss, doesn't show up at all at narrower widths. Not that it was an important note, but we're talking principle here.
My mini-gripe is the typography: While I'm typically a dark mode guy, thin fonts are a lot harder to read in dark mode. But I've seen worse.
If you start from scratch, factor it in when deciding on a cms, platform or site generator. I think RSS/atom owes a lot to WordPress, which has it enabled by default since ages.
When you want to add it retro-actively, the specifications are relatively straight forward and don't have many mandatory properties. RSS is a tad simple than Atom, but I'd probably rather go for Atom if I were to start over.
Also, JSON Feed [0] is still better than nothing, many of the major RSS readers quietly support it, and does have the small advantage that JSON is much easier to work with in more platforms than XML today.
Most CMS/blog apps have it built in. You might need to look up how to enable it (Drupal) or you might already have it enabled, even if you don't realize it (Wordpress). Check the documentation for your blogging/site content framework of choice.
If you're super old school and do an actual manual HTML site, just create the RSS file and add entries to it, then link to it. This is well documented and not in any way complex. It's just a text file, after all.
> If you're super old school and do an actual manual HTML site, just create the RSS file and add entries to it, then link to it.
Make use to add an <link rel="alternate" type="application/rss+xml" href="feed.rss"> element and not just a normal hyperlink so that users can just paste your blog URL into their feed reader to subscribe without having to search for the feed link. Ideally this should be present in the page for both the index as well as every article.
I might cop a lot of hate for saying this, but it's been 10 years, it's time to stop mourning RSS and move on.
I loved RSS, I sorely miss the protocol based internet rather than the web based internet we have now. I miss when my emails didn't have adverts pretending to be emails at the top of my inbox.
Advertising was a lot less prevalent when applications had protocols and you could simply move to a different client with fewer (or no) adverts.
This take, popular though it is, seems to be more vibes-based than reality based. Most blogs I visit have RSS feeds. The site we’re both currently posting on has a fully functional RSS feed. It’s hardly dead.
I always thought HN doesn't have RSS, that's why https://hnrss.org was created if I'm not mistaken. I just saw there is actually a feed for the main page.
> I might cop a lot of hate for saying this, but it's been 10 years, it's time to stop mourning RSS and move on.
I can't comprehend where this notion that RSS is somehow "dead" is coming from. RSS is ubiquitous: every major blogging platform, aggregator, and other media site continues to offer feeds, including all of the major video sharing sites. The entire podcasting ecosystem is based on RSS.
I consume HN, Reddit, Lobste.rs, about a hundred blogs, a hundred podcasts, YouTube and lots of other sui generis stuff all via RSS feeds, subscribed in TT-RSS with Liferea as a frontend.
RSS hasn't gone away and is not going away.
> I loved RSS, I sorely miss the protocol based internet rather than the web based internet we have now.
It hasn't gone anywhere. If you miss it, consider the possibility that you yourself have followed the garden path away from it, and forgotten the way back.
Yeah I subscribe to everything from major tech news sites (Ars Technica, The Verge for example) to tiny blogs. RSS is very widely adopted, even if nobody is making noise about it or trying to hype it up. Anything but dead.
In this case "moving on" means adding in social media "share beacons", which just so happens to load their 3rd party cookies and analytics scripts, and shuttle that web traffic information back to the motherships.
Most of my media content is podcasts, and I still consume all of my podcasts via RSS feeds. I have yet to run into a podcast where this did not work. RSS isn't the past, it's the future, and painting it as dead is an odd characterization in my view when it's alive and well.
> and I still consume all of my podcasts via RSS feeds.
Considering that a podcast is an RSS feed, it's not like there's any other option. People using fancy modern podcast apps might not be interacting with the RSS feed directly, but the software they're using certainly is.
Spotify exclusive "podcasts" aren't really podcasts any longer. They're Spotify Exclusive Content calling themselves something that's no longer valid. The same is true of any platform exclusive content.
The world's most popular podcast used to be The Joe Rogan Experience, but since Spotify acquired exclusive rights to it, it is no longer distributed as a podcast, and is only available as a Spotify channel. Despite continuing to call it a "podcast", it isn't actually a podcast anymore.
OpenRSS is a service that creates RSS feeds using web scraping. Unfortunately, it can't create enclosure links for audio content that's sitting behind Spotify's paywall, so this isn't a podcast feed.
JRE simply isn't a podcast anymore. It's just a Spotify channel.
Time to move on to what? Time to move back to everything being a chaotic jungle of different designs & experiences? I think not. Even if sites themselves don't support rss, there's many tools out there to help res-ify various sources. If there was a way to move on maybe we might eventually drop rss/atom, but it seems highly highly unlikely we'll move back from rss.
I love the web & it's great solid platform. But rss holds a special place in my heart too. Calling rss "not the reality of the modern web", saying that we should just except captive experiences by the valent forces doesn't seem very web-like to me, doesn't bespeaks the user-agency that so critically distinguishes the web from everything else. The internet is for end users, rfc8890, and rss is a strong manifestation of that value.
If we do want to move on we have to make that new place.
WHOA! This is shocking ignorance for an HN user. RSS still exists for most of the web if you can be bothered to use it. It just isn't in your face anymore. I consume a lot of content through RSS to this day. You also don't need to look at those email adverts if you can be bothered to use real email apps. It's your choice to soak yourself in the dumbed down garbage interfaces.
They are not ignorant just for holding a different opinion.
My entire reading system is built on RSS but I don’t think it’s an invalid take to say that RSS is a thing of the past, or at the very least that the train has left the station. Every month I have some feed just randomly die because nobody paid attention or cares anymore. It’s pretty unfortunate.
Browsers should never have backed off exposing it, IMO.
> They are not ignorant just for holding a different opinion.
No, but this isn't a contest of opinions. The claim that RSS unsupported, no longer in widespread use, and/or is merely a remnant of a previous era is factually incorrect.
> don’t think it’s an invalid take to say that RSS is a thing of the past
Sorry, but it's an invalid take. I don't know what sites you're using that stopped offering RSS, but I have hundreds of blogs, podcasts, and aggregators, along with my favorite subrreddits, YouTube channels, etc. all subscribed via RSS, and the only time anything "dies" is when a blog or podcast changes its URL.
> The claim that RSS unsupported, no longer in widespread use, and/or is merely a remnant of a previous era is factually incorrect.
I did not say they were factually correct, merely that I'd lump RSS in with "things of the past" given how many sites and developers neglect it nowadays. I was pretty clearly saying that their opinion isn't unfathomable to me.
The slow decline of RSS is not some new topic and this very site has discussed the topic for the better part of a decade. You're free to feel whatever you'd like tho.
> I did not say they were factually correct, merely that I'd lump RSS in with "things of the past" given how many sites and developers neglect it nowadays.
I mean, I assume that number must be greater than zero, and yet I seem to be having a hard time identifying any sites or blogging applications that do indeed neglect RSS. All of the sites I frequent support it. Do you have any meaningful examples of this alleged lack of widespread RSS support?
> The slow decline of RSS is not some new topic
Unfortunately not -- people have been pretending it's happening for years without any real evidence to sustain the claim. If I were more of a conspiracy theorist, I'd suspect that maybe it's something they're trying to make happen.
Most major websites continue to offer RSS. Considering that some people apparently believed that HN itself did not have RSS, I suspect that some people just don't know where to look for feed URLs.
That's OK though - it should be enough for text content. I think it's also OK to just have the RSS feed contain the title and summary of the article since I prefer to read the content in my browser anyway - but there are definitely different opinions here.
I went pretty far in the direction of these features on my personal sites in the 2010s. They are fun coding and design challenges.
Nowadays I am going the other direction. For the most recent design on my personal site, I even have a “no footnotes” rule, on the theory that (for me at least) footnotes can be an indication of scattered thinking and/or insufficient editing.
My thoughts exactly. There is a time and place for footnotes, sidebars, and citations, but they take attention away from the body text and, when overused (gwern.net), the entire site can look cluttered and disorganized. Most people aren't going to read these things anyway, so you're better off focusing on concise, effective writing.
Nowadays it's like every single blog and website will "popup" something everytime i select text. It annoys me to no end, because I select text as I read along and it's incredibly annoying.
Whether be it ChatGPT, medium articles, and recently even Google search!
UBlock Origin allows you to block JavaScript by default on all websites, and it's what I do. And Firefox has something called reader mode. Absolutely fantastic tools.
If you don't want to outright block all JavaScript you can just block 3rd party scripts, it usually lets you see if the website uses some fuckery or not.
A feature that seems to have disappeared from a lot of blogs these days is date when a post was published. Sometimes date is required to put things into context and I can't understand why so many blogs these days don't have it.
I have actually three dates on my blog [1], (1) the date I started writing a post (hardcoded in the url/name), (2) the date it was first published (defined in the markdown frontmatter) and (3) the date a post was last modifed (based on git commits). I think all three are relevant.
I like the second and third date but I think the first is perhaps a little confusing to me without this context. If I didn't know this is what it meant I'd of thought they'd be some bug in your blog or you forgot to update the url
Google knows whether your content is recent or not regardless if you have a timestamp on it, because they crawl periodically and according to recent leaks they do store this information.
It's hard to tell if they use it. Most of SEO is just cargo-culting because of how difficult it is to experiment with it. Somebody once said it helped them to remove the date, and now everyone does it. Maybe google is using it, or was using it at some point. Maybe they use the date in structured data [1] because it's easier to get and potentially more reliable (telling content changes and theme changes apart isn't trivial), and people just noticed that if they turn off the date feature in their CMS their articles rank better.
Unfortunately, it's not hard to make a few tweaks though and have it look "updated" to the crawler. I imagine Google could change that (especially now with LLM tech possibilities) so I guess we'll see what happens, but so far it hasn't hurt the career "optimizers" that I know.
Others have commented on it being SEO-related, but I think there might be a psychological component to it as well, where you don’t want people to bounce because they think it’s an old and irrelevant article.
It used to be that a book or magazine issue needed to have a copyright notice including the year of publication or it didn't get copyright protection. That was a good rule.
And even if you see dates, quite often they're relative. A year ago could mean a lot.
Oh, and while blogs are usually newest on top, relative dates break the ability to derive sort order by looking at multiple values, if they're all the same.
A similar thing that really perplexes me is that GitHub uses relative dates. You try to find the date a certain change was made, and you end up scrolling through page after page of "six years ago."
It feels like the sort of thing that is only really sticking around because it was a design trend many years ago when some of these apps were written.
The for-profit web surfs the eternal wave of "now". Anything that happened in the past is disregarded by search indexes, social media, and people using them.
My URLs have the date in them, and all posts have the original date near the title. I do updates (and update internal metadata), but removed the modification date because it was confusing to people…
Only really works if one article takes up most of the space. If there's tons of ads/coments below, the scrollbar would show less progress than actually is the case, and vice versa with wasted space above the article.
Great list of things to think about for a good reading experience. Linkable headings is my favorite. I will often grab the IDs from source when needed. Hard pass on the external link decoration though. Please just don't break the back button and everything will be fine.
It's not a feature, but I like websites without sticky headers or footers.
I hate seeing it on mobile, but I don't like it even on desktop.
The worst is the sticky side button overlapping the main content.
A few years ago, I sometimes saw "share on social media" buttons obscuring the article, and that was so annoying.
I think that is a good default. A small number of sites seem to execute sticky elements that help with long content, but only add it if you are going to test it.
I use the top of the page to track where I am reading.
When a header is hidden on scrolldown, and shown on scrollup, that breaks a core feature that I was actively using.
To make matters worse, scroll direction is incredibly finicky on mobile, so I can't even consistently decide whether your ridiculous header is shown or not.
Good list, though here comes my Hacker News-style pesky comment:
Justified text on a screen is a feature that makes my eyes and brain hurt.
Ragged text is much easier to read. Uneven and beautiful, like a plant whose details you rest your eyes upon as you observe, rather than a uniform concrete structure where vision is lost.
This is absolutely it for me. It's also why I like paragraphs to have some level of spacing between them.
I'm currently reading a book that has quite minimal indentation on the first line of a paragraph, no spacing between, small font, and justified text. Every page is just a wall of text. It makes it noticeably more tiring to read than others that I've read recently. It seems to be a trend in more serious historical tomes. The last one I read, the Beauty and the Terror, was similarly typeset.
It's one of the reasons I like reading on my kindle.
And lowercase letters are easier to read than ALL CAPITALIZED LETTERS IN A HORIZONTAL LINE OF TEXT.
Justified text is the same thing, but vertically. Your eye reaches the end of the line, and the next one is likely slightly longer or shorter, so it is easier for your eyes to find the next line instead of reading the same line over again, and also easier to see the whole shape of a particular paragraph you want to refer to later.
I do like well-hyphenated justified paragraphs in print, that also let you fit more words per page. But even there, I prefer the organic, non-uniform look of ragged text.
Agreed! I wrote a blog post about this a couple years back.[1] A few things I think are going on:
- layout and hyphenation algorithms on the web are worse (or often disabled!)
- the lines are often too long
- the site's margins aren't as strong as with print design
These factors combine to produce the mess you're describing.
I've spent so much time reading justified text in print that I do like it in general. But I think until places like NYT or Medium adopt it on their websites, it's probably not up to snuff on the web.
> I would like to take this opportunity to complain that LaTeX iS cApItAlIzEd lIkE tHiS.
In case you were complaining because you don't know why, rather than because you knew why but don't like it, it's LaTeX because it's Lamport + TeX; and it's actually not really TeX but TEΧ (that last letter is a chi), which, when typeset properly (see https://upload.wikimedia.org/wikipedia/commons/thumb/6/68/Te...), was meant specifically to show off TEΧ's layout abilities.
> Way back when, we used to call ASCII like ":)" smilies, didn't we? I'm so old I don't even remember clearly. x_x
I always thought that ~it's only called Champagne if it's from the Champagne region of France~ it's only called a smiley if it's smiling. But, according to https://en.wikipedia.org/wiki/Emoticon (and as confirmed by http://www.cs.cmu.edu/~sef/sefSmiley.htm), their progenitor Scott Fahlman gave :-( as a prototypical example, so what do I know?
And Windows actually has a library of them for easy insertion. It's part of the same interface as selecting emoji. Just hit Win+. (Win+{Period}) and switch to the ";-)" tab.
Sometimes referred to as smilies, though IMO that word describes the 3ish character subset that look like a face at 90 degrees⁰, and predating emoji¹ by quite some time².
----
[0] Like :-)
[0] and many many others: ;-) :-( :-| :-p 8-) …
[1] the graphical alternatives
[2] first commonly used in the early 80s, even before my time online, where emoji turned up right at the end of the 90s
Justified text is beautiful ... in narrow-ish columns with good hyphenation. But hyphenation sucks on the web, and without hyphenation you can't even do narrow columns even in the rare cases where it would make sense for the reader.
Browsers take hyphenation hints: insert ­ in a word to tell it that it can put a hyphen there. Either combined with css ´hyphens: auto´ to tell the browser to also choose where to put hyphens, or ´hyphens: manual´ so your hints are the only thing that counts. Then just do it all server-side. Browsers still aren't the best at actually using that, but it's better than not hyphenating at all. (and of course you could write your own layout engine that uses your soft hints)
But shipping a whole dictionary wouldn't even be that unreasonable. A reasonable English dictionary is about 1.5MB compressed or 4MB uncompressed.
I like Cassidy James' idea of linking a blog post to a Mastodon post[1], and showing the corresponding social interactions as a comments section at the bottom of the post. All static site client-side!
> Using Mastodon to power our comments means that every time someone visits the blog post, the user’s browser makes a request to your Mastodon instance. ... I’d proxy these requests through my server, but it’s yaks all the way down.
I do proxy these, and it's not too much work [1]. A major reason to proxy is so you can cache: if a blog post gets HN'd it could easily get more traffic than your Mastodon instance would like to receive.
I think by "proxy the requests", they mean, these are usually on a static site and the browser is directly pulling in the Mastodon content client-side. They want to be good citizens and add a caching layer that they run.
WordPress used to have a Links section in the sidebar by default. It was later criticised for the default links being to WP founders/devs. But it was there, and you could change it.
Links are the web for me. "If you like my site maybe you will like what I like".
Back in the day (late 90's to early 2000's), sites would have something called a webring where sites would link to similar sites in a circular fashion. It was a good way to find similar sites and kinda a fun adventure.
I like the side notes feature, but the hiding feature ins't great. IMO They should go with responsive design to inline the side notes if the screen is small.
443 comments
[ 6.7 ms ] story [ 306 ms ] threadBut I like the way it's handled on fasterthanli.me enormously - the author there successfully anticipates a lot of my "wait, but..." thoughts and addresses them directly via this mechanism, or, conversely, makes me realise that I ought to have had an objection to the point they're making.
* Each character has very visually distinct designs (ideally each is as distinct as I can reasonably make them, to the point where I have different artists do each one)
* The names have meaning (Aoi means blue, Aoi's hair is blue)
* Each character has an archetype that corresponds to a facet of how I understand technology, and their interactions are intended to reflect those internal disagreements or touch on the intentionally placed "learning lies" (the simplifications of how things work intended to give people a starting point for understanding an abstract thing that can later be discarded when they dig into the details and realize that shit's actually complicated)
I've been idly considering adding something to the message footer in faint text with a tl;dr like "(the student)" for Aoi, or "(the well-intentioned forum troll)" for Numa. Would that help?
I originally was kinda hesitant to do this under the axiom that if you have to explain your art, you fucked it up. I'm willing to concede that it's probably a bad axiom for me to follow here.
I'd always thought that inline dialogs with fictional characters were more for the author's entertainment than the reader's, so I was surprised OP and others in the thread like them.
I have nothing against them if people like them; just a matter of taste.
Somewhere in the middle, is decades of the "…for Dummies" technical manual formula and its stock dialog characters and the love affair many had (or still have) with "The Poignant Guide to Ruby".
Dialogs can definitely be hard to read in the context of just reading a single blog post because you don't have a familiarity with that author's characters and most blog authors don't have a "shared universe" of characters. I wonder if there's an interesting world where for instance the Dummies characters were considered to be public domain at the right time or more blog writers felt confident with _why's unique voices to turn Poignant's characters into a modern "Punch & Judy" for technical writing. The Socratic Method worked because everyone had a shared intuition on the characters of the day (in part because many were famous Senators and/or Wrestlers): Plato, Socrates, Aristotle, etc. (Also, Plato was his wrestling name, these were absolutely characters.) Maybe if we want to use more Dialogs in blog posts easily we need better shared characters?
It’s also possible to use a question-answer style without having a dialog and characters. What would that look like? Well, similar to this very paragraph. Not that I would particularly recommend it either.
Also, I'm confused about some points. For example, is progress meter really necessary? I mean, isn't the scrollbar a good indicator for the progress?
I'm personally a huge fan of the progress meter (having once thought it was redundant as well) - one other easy addition I didn't see mentioned is an "estimated reading time." Having a ballpark range for how long I should expect to spend with a piece of content greatly increases my chance of engaging with it, and the progress meter creates a tangible representation of that time (and how much of it I have left to finish consuming the content).
As for "progress meter" being an optimization of websites with large footers or long lists of comments, I'd argue that a better optimization technique would be to remove the footer, or remove/hide by default list of comments (i.e. make it available with a mouse click somewhere).
Do you mean for non-native speakers reading English material or for material in other languages when read by native speakers with an average reading competence in their native language?
Anyhow, as a non-native English speaker, it implemented it on my site by showing both the word count, as well as an estimated time, which is simply calculated by dividing the word count by a constant number of assumed words per minute.
That number was guesstimated by doing some reading speed tests on myself and researching average reading speeds and rounding up to 10 wpm. I have to admit that my assumption of 240 words per minute does not hold up to any scientific scrutiny, but otoh it is an estimation.
It works ok for prose. As soon as other notation is mixed in (code, math, graphs, diagrams etc.pp) that begins to naturally to vary wildly in accuracy.
Do you mean people whose native language is not English? I assume it works the same way as for everyone else, i.e. it's always an approximation anyway. I'm not from an English-speaking country, but I'm pretty sure I read faster than the average English native.
The other interpretation is that you mean people who can't read English at all, but in this case I understand even less. They won't be able to read the article, if they don't speak the language. After automated translation, the reading time should be roughly correct again.
so i’ll agree that progress indicators are helpful for this use case.
I think the better solution in this case is to use the (relatively) new html tags: <details><summary>Comments</summary></details>
Demo:
https://try.scroll.pub/#scroll%0A%20%0A%20expander%20Comment...
Progress meter is also at 0% when you're not scrolling, so unless you scroll, you don't know how much text there is to read.
(btw, just checked for Firefox and Safari, and the scrollbar is visible at all times, unless the website explicitly hides it)
There is a setting for this called "Always show scrollbars" and I know it defaults to off for me. The underlying about:config rule is specific to GTK though, so this may be platform-specific.
But also I don't really get how people are fine with hiding the scrollbar, but prefering to see the progress meter always visible for text, when the scrollbar conveys mostly the same information (except some edge cases when the footer is long I guess).
Not that it's important at all, I'm just at loss and it's not the first time I'm getting a signal that sometimes I simply don't understand people. But of course that's fine.
On macOS, at least, this is a setting so you can make them visible or invisible according to your taste. Probably not available on phones, though.
Here is a few additional things not on your list that I love and have implemented on my blog:
- Plain text versions of all posts. Change the file extension on any page on my site from ".html" to ".txt" to view it as plain text (https://breckyunits.com/intelligence.txt). Makes it easy to copy/paste a whole post into an email or Reddit submission
- View source links at the bottom of every page. Every post is 1 file tracked by git, and I put a "View source" link at the bottom of each page. Even the static pages are also one file, and also have a View Source link.
- Clientside full text search - https://breckyunits.com/search.html.
- CSV export. In addition to RSS, you can download my site as CSV (https://breckyunits.com/posts.csv).
- Keyboard nav. Use the left/right arrow keys to navigate through pages on my site.
- Helpful 404s. If you mistype a url, the 404 page compares it to working urls and shows you the closest match. All done using clientside JS (no web server needed). For example: https://breckyunits.com/pcr.html
- Download entire site and read offline. Everything is designed to work fine locally and you can download the whole thing as a zip. (The link is at the bottom of every page)
- Printable. Everything is designed to look decent printed. Nav elements are hidden via CSS when you go to print. I haven't added automatic generation of PDFS yet, but that is on my todo.
Please don't, this is horrible and I've previously only seen it used by clickbait news sites.
It provides no real value, the only use case of somebody wanting to browse through just the start of each of your articles is going to be incredibly rare. But what you're doing is hijacking a key that normally has no effect into having a destructive one. All it takes is a minor keyboard fumble while trying to scroll, and you've just lost all context and confusingly taken to some totally unrelated article.
> It provides no real value,
This is wrong. It provides a tremendous amount of value. Source: I use it many times a week, for many years, for many reasons.
> destructive one.
This is wrong. These pages are immutable with no state. If by chance you accidentally hit an arrow key on one of the rare long form pages with scroll, sure you lose about 50 milliseconds of time getting back to your prior scroll level. In years of doing this not a single person has ever complained, while instead a number have commented that they like it.
I've never used your website, but if I did and the side arrow changed things, I'd immediately close it and never come back. You wouldn't get a complaint from me; you'd just lose me instantly and permanently.
It drives me absolutely nuts when sites do this, it is so disorienting.
Do you think this concerns me?
I don't make this site for you, someone who admits they've "never used" my site.
I make my site for my regular readers, some of whom have been reading the site for over 10 years.
The people who regularly email me comments and feedback on my posts. People who _love_ the fact that they can flip through the entire blog in seconds using the arrow keys.
> when sites do this
My site is not like other sites on the web. In fact, it is such an outlier, that I've recently started a new successor to the WWW, called the World Wide Scroll, to start aggregating more sites like mine.
My site is entirely public domain, has no advertising or trackers or cookies, can be downloaded in 1 click and used entirely offline, is written in a new language (Scroll) that is mathematically shown to be the simplest/most powerful language yet invented, that compiles to HTML/CSS/JSON/XML/RSS/plain text, is fully tracked by git so you can see the history of every line in every file.
This is, at best, ambiguous. To show something mathematically, you have to have a precise definition of it, and neither "simple" nor "powerful" admits a precise definition that is widely agreeable enough for any mathematical proof based on it to be worth anything.
I point you to https://breckyunits.com/pcri.html
Further background:
- https://breckyunits.com/intelligence.html
- https://github.com/breck7/breckyunits.com/blob/main/research...
- https://github.com/breck7/breckyunits.com/blob/main/research...
- https://github.com/breck7/breckyunits.com/blob/main/research...
The problem of losing context can be mitigated by having the page return to the previous location on back, something which browsers kinda already do, just not very well.
Alternatively, I assume you'd prefer some kind of modifier? This has problems of its own — e.g. shortcut clashes. YouTube uses comma and full stop as frame next/previous shortcuts — maybe we should standardise on those?
Very neat! Many other are cool too.
I haven't found a nice way to do this on both desktop/mobile. What I want is for every heading to have an anchor link that can be copied, similar to a hyperlink. I see a lot of sites do this with a [unicode chain symbol] which is present on hover, but that's not an option on mobile. Alternate option is to have it next to every heading (ugly), turn every heading into a hyperlink without styling, or make them look like regular hyperlinks which I think is confusing.
[1]: https://ahmetsait.com/blog/en/Hello-World
/* keep the icon hidden by default */ :is(h1, h2, h3, h4, h5, h6) .icon { visibility: hidden; }
/* show the icon on focus and hover */ :is(h1, h2, h3, h4, h5, h6):focus .icon, :is(h1, h2, h3, h4, h5, h6):hover .icon { visibility: visible; }
/* show the icon on devices that don't have any accessory that can hover */ @media (pointer: coarse), (any-hover: none) { :is(h1, h2, h3, h4, h5, h6) .icon { visibility: visible; } }
The `pointer: coarse` media query checks if you are using a device with an input mechanism of limited accuracy (such as fingers on a touchscreen). The `any-hover: none` media query checks if none of the input mechanisms on your device support hover (such as a Surface tablet not attached with a keyboard).
It's all based a static site and it relies on HTMX for this feature. I've also made sure the page works without JS. For now it is a bit rough and sometimes it may not be clear that it opened underneath but I want to explore this a bit more.
Regarding the Table of Contents feature, however, I believe this makes a big difference in larger blogs, but for medium sized or smaller blogs, it can be a distractor. I use Hugo as well for compositing my site, and find that using ample first level headings (e.g., # Heading name) for major components alongside a solid flow that contains visual graphics placed shortly after the heading offers an attractive and easy-to-navigate browsing experience.
Ah. That resonates. Thank you for breaking it down like that. I've pondered adding ToC, but now realize it's only for a small subset of pages that it adds value, rather than distracts.
But the problem for me is that good headlines, that give a fair summary of the section they are for, make for really wide tables of contents which don't fit neatly into the margins[4], so sometimes the table of content has to occupy space in the main section[5] which seems to me like it distracts a bit from the actual content.
[1]: https://two-wrongs.com/markov-chains-for-queueing-systems.ht...
[2]: https://two-wrongs.com/verifiable-software-development-estim...
[3]: https://two-wrongs.com/event-sourcing-and-microservices-unix...
[4]: https://two-wrongs.com/word-embeddings-in-perl.html
[5]: https://two-wrongs.com/what-is-probability.html
[1] https://github.com/FrostKiwi/treasurechest/blob/4d96694a912e...
[2] https://blog.frost.kiwi
[1] Example https://www.notion.so/notion/Table-of-contents-50de58f824bf4...
My mini-gripe is the typography: While I'm typically a dark mode guy, thin fonts are a lot harder to read in dark mode. But I've seen worse.
When you want to add it retro-actively, the specifications are relatively straight forward and don't have many mandatory properties. RSS is a tad simple than Atom, but I'd probably rather go for Atom if I were to start over.
https://www.rssboard.org/rss-specification
https://validator.w3.org/feed/docs/atom.html
In any case: add a link rel=feed to the header of every page to enable discovery (https://www.rssboard.org/rss-autodiscovery - but works regardless of the format)
[0] https://www.jsonfeed.org/
If you're super old school and do an actual manual HTML site, just create the RSS file and add entries to it, then link to it. This is well documented and not in any way complex. It's just a text file, after all.
Make use to add an <link rel="alternate" type="application/rss+xml" href="feed.rss"> element and not just a normal hyperlink so that users can just paste your blog URL into their feed reader to subscribe without having to search for the feed link. Ideally this should be present in the page for both the index as well as every article.
I loved RSS, I sorely miss the protocol based internet rather than the web based internet we have now. I miss when my emails didn't have adverts pretending to be emails at the top of my inbox.
Advertising was a lot less prevalent when applications had protocols and you could simply move to a different client with fewer (or no) adverts.
But that's not the reality of the modern web.
And it doesn't do much good to pine for the past.
I can't comprehend where this notion that RSS is somehow "dead" is coming from. RSS is ubiquitous: every major blogging platform, aggregator, and other media site continues to offer feeds, including all of the major video sharing sites. The entire podcasting ecosystem is based on RSS.
I consume HN, Reddit, Lobste.rs, about a hundred blogs, a hundred podcasts, YouTube and lots of other sui generis stuff all via RSS feeds, subscribed in TT-RSS with Liferea as a frontend.
RSS hasn't gone away and is not going away.
> I loved RSS, I sorely miss the protocol based internet rather than the web based internet we have now.
It hasn't gone anywhere. If you miss it, consider the possibility that you yourself have followed the garden path away from it, and forgotten the way back.
But they can extended or innovated beyond!
There's just no candidates of note for any other strategies.
Here's a nickel, get yourself a better email client.
No thanks. I'll stick to RSS.
Considering that a podcast is an RSS feed, it's not like there's any other option. People using fancy modern podcast apps might not be interacting with the RSS feed directly, but the software they're using certainly is.
https://feeds.megaphone.fm/GLT1412515089
Looks like Megaphone is a real, honest-to-goodness podcast hosting service that's owned and operated by Spotify, with proper RSS feeds and everything.
JRE simply isn't a podcast anymore. It's just a Spotify channel.
I love the web & it's great solid platform. But rss holds a special place in my heart too. Calling rss "not the reality of the modern web", saying that we should just except captive experiences by the valent forces doesn't seem very web-like to me, doesn't bespeaks the user-agency that so critically distinguishes the web from everything else. The internet is for end users, rfc8890, and rss is a strong manifestation of that value.
If we do want to move on we have to make that new place.
My entire reading system is built on RSS but I don’t think it’s an invalid take to say that RSS is a thing of the past, or at the very least that the train has left the station. Every month I have some feed just randomly die because nobody paid attention or cares anymore. It’s pretty unfortunate.
Browsers should never have backed off exposing it, IMO.
No, but this isn't a contest of opinions. The claim that RSS unsupported, no longer in widespread use, and/or is merely a remnant of a previous era is factually incorrect.
> don’t think it’s an invalid take to say that RSS is a thing of the past
Sorry, but it's an invalid take. I don't know what sites you're using that stopped offering RSS, but I have hundreds of blogs, podcasts, and aggregators, along with my favorite subrreddits, YouTube channels, etc. all subscribed via RSS, and the only time anything "dies" is when a blog or podcast changes its URL.
I did not say they were factually correct, merely that I'd lump RSS in with "things of the past" given how many sites and developers neglect it nowadays. I was pretty clearly saying that their opinion isn't unfathomable to me.
The slow decline of RSS is not some new topic and this very site has discussed the topic for the better part of a decade. You're free to feel whatever you'd like tho.
I mean, I assume that number must be greater than zero, and yet I seem to be having a hard time identifying any sites or blogging applications that do indeed neglect RSS. All of the sites I frequent support it. Do you have any meaningful examples of this alleged lack of widespread RSS support?
> The slow decline of RSS is not some new topic
Unfortunately not -- people have been pretending it's happening for years without any real evidence to sustain the claim. If I were more of a conspiracy theorist, I'd suspect that maybe it's something they're trying to make happen.
I have email without advertisements.
Some web sites will have RSS, and you can add it to your own if you want to do. (Although I think Hina-Di is better in some ways)
Other protocols also are still used, even if not as commonly. (I use IRC and NNTP, too.)
Nowadays I am going the other direction. For the most recent design on my personal site, I even have a “no footnotes” rule, on the theory that (for me at least) footnotes can be an indication of scattered thinking and/or insufficient editing.
Whether be it ChatGPT, medium articles, and recently even Google search!
UBlock Origin allows you to block JavaScript by default on all websites, and it's what I do. And Firefox has something called reader mode. Absolutely fantastic tools.
[1]: https://du.nkel.dev/
1: https://developers.google.com/search/docs/appearance/structu...
And it ends up being an ad for some service.
I also have a couple of other things I look for in a good blog: https://j11g.com/2024/06/24/a-good-blog-has/
Oh, and while blogs are usually newest on top, relative dates break the ability to derive sort order by looking at multiple values, if they're all the same.
It feels like the sort of thing that is only really sticking around because it was a design trend many years ago when some of these apps were written.
I just look at the scroll bar.
But yes, the scrollbar ought to be enough.
The worst is the sticky side button overlapping the main content. A few years ago, I sometimes saw "share on social media" buttons obscuring the article, and that was so annoying.
When a header is hidden on scrolldown, and shown on scrollup, that breaks a core feature that I was actively using.
To make matters worse, scroll direction is incredibly finicky on mobile, so I can't even consistently decide whether your ridiculous header is shown or not.
Justified text on a screen is a feature that makes my eyes and brain hurt.
Ragged text is much easier to read. Uneven and beautiful, like a plant whose details you rest your eyes upon as you observe, rather than a uniform concrete structure where vision is lost.
(╯°□°)╯︵ ┻━┻
┬─┬ノ( º _ ºノ)
I'm currently reading a book that has quite minimal indentation on the first line of a paragraph, no spacing between, small font, and justified text. Every page is just a wall of text. It makes it noticeably more tiring to read than others that I've read recently. It seems to be a trend in more serious historical tomes. The last one I read, the Beauty and the Terror, was similarly typeset.
It's one of the reasons I like reading on my kindle.
And lowercase letters are easier to read than ALL CAPITALIZED LETTERS IN A HORIZONTAL LINE OF TEXT.
Justified text is the same thing, but vertically. Your eye reaches the end of the line, and the next one is likely slightly longer or shorter, so it is easier for your eyes to find the next line instead of reading the same line over again, and also easier to see the whole shape of a particular paragraph you want to refer to later.
I do like well-hyphenated justified paragraphs in print, that also let you fit more words per page. But even there, I prefer the organic, non-uniform look of ragged text.
- layout and hyphenation algorithms on the web are worse (or often disabled!)
- the lines are often too long
- the site's margins aren't as strong as with print design
These factors combine to produce the mess you're describing.
I've spent so much time reading justified text in print that I do like it in general. But I think until places like NYT or Medium adopt it on their websites, it's probably not up to snuff on the web.
(edit: formatting)
[1] https://maxwellforbes.com/posts/web-justified-text/
In case you were complaining because you don't know why, rather than because you knew why but don't like it, it's LaTeX because it's Lamport + TeX; and it's actually not really TeX but TEΧ (that last letter is a chi), which, when typeset properly (see https://upload.wikimedia.org/wikipedia/commons/thumb/6/68/Te...), was meant specifically to show off TEΧ's layout abilities.
(In fact Lamport got into the spirit of it, and the real name is LATEΧ, again carefully typeset: https://upload.wikimedia.org/wikipedia/commons/thumb/4/45/La... . The common stylization LaTeX is just a convenient ASCII representation.)
o_o
> o_o
> “quasi” emojis
Welp, if you need me I'll be shuffling my weary bones into a casket.
So I tied an onion to my belt, which was the style at the time...
I always thought that ~it's only called Champagne if it's from the Champagne region of France~ it's only called a smiley if it's smiling. But, according to https://en.wikipedia.org/wiki/Emoticon (and as confirmed by http://www.cs.cmu.edu/~sef/sefSmiley.htm), their progenitor Scott Fahlman gave :-( as a prototypical example, so what do I know?
︵ ┻━┻
https://en.m.wikipedia.org/wiki/List_of_emoticons
----
[0] Like :-)
[0] and many many others: ;-) :-( :-| :-p 8-) …
[1] the graphical alternatives
[2] first commonly used in the early 80s, even before my time online, where emoji turned up right at the end of the 90s
I don't plan to ever do something like this for any purpose, and I have never seen anybody do it either... But you can.
But shipping a whole dictionary wouldn't even be that unreasonable. A reasonable English dictionary is about 1.5MB compressed or 4MB uncompressed.
1. https://cassidyjames.com/blog/fediverse-blog-comments-mastod...
https://jszym.com/blog/mastodon_blog_comments/
> Using Mastodon to power our comments means that every time someone visits the blog post, the user’s browser makes a request to your Mastodon instance. ... I’d proxy these requests through my server, but it’s yaks all the way down.
I do proxy these, and it's not too much work [1]. A major reason to proxy is so you can cache: if a blog post gets HN'd it could easily get more traffic than your Mastodon instance would like to receive.
[1] https://github.com/jeffkaufman/webscripts/blob/master/commen...
WordPress used to have a Links section in the sidebar by default. It was later criticised for the default links being to WP founders/devs. But it was there, and you could change it.
Links are the web for me. "If you like my site maybe you will like what I like".
Go look at https://diamondgeezer.blogspot.com/ - links!
Go look at other sites and if they are WP chances are no link list.
Am I blaming WP? Yes because I thought it was a terrible change. No because other site builders/SSG's appear to have followed.
Links make the web what it is.
We need more, not less.
I miss them. Now get off my lawn, I have wind mills to slay.
- flash/highlight the fragment when clicking a link to it. Also, adding some padding for making sure the header is not covering part of the fragment
- an alternative to sidenotes is to use an initially collapsed details/summary element.
- inlining css, js, and svgs so it can be saved as a single html file
This post has some examples of those features:
https://blog.uirig.com/freebsd-jails-network-setup#-rcconf
Or just use http2 and have a much better organized code without need to build/bundle them together.