（评论）
(comments)

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

在本文中，作者论证了删除移动设备上由于使用过程中的意外触摸而导致的传统滚动条的重要性。他们比较了滚动条从早期计算系统到当前状态的演变，并提供了电子墨水平板电脑和滚动不精确性的个人体验。作者重视使用空格键或跳转链接等各种方法翻阅长文本或显示的便利性，并批评了在移动设备上滚动的缺点，包括不精确的接触点、模糊的查看区域以及与滑动手势的潜在混淆。 The text concludes with the author's preference for scroll-free alternatives。

Many of these suggestions are good. (I should make my subheds clickable!) But a couple of them, oh dear…

I really hate progress bars, they are incredibly distracting. One of the worst examples of front end programmers wasting their time reimplementing browser functions badly. I already have scroll bars! I do not need more scroll bars!

Also, link decoration: my browser already has a nice discreet indicator to tell me where a link goes, I don’t need or want mysterious dingbats in the running text. (It reminds me of websites that are so scared of hyperlinks that they send them via interstitial warning pages “YOU ARE LEAVING THE SITE!!!!1!1!”, or in a recent case via a $yber$ecurity box that broke the link completely.) And preview popups? Get in the sea, hostile obnoxious interruption.

I think progress bars are a logical consequence of the user-hostile shrinking of the scrollbar. Unusable, narrow things which are often hidden by default, and rarely have a visible elevator (or thumb) anymore. Of course, scrollbars are often entirely useless in pages which insist on loading content piecemeal -- another user hostile pattern.

Obvious solution is obvious: restore the fucking scrollbar.

I suspect a strong driver of scrollbar deprecation is the overwhelming dominance of small-screen touch-based mobile devices. An active scrollbar, that is, one which not only shows page scroll depth, but controls it via touch, is one more UI element to generate annoying behaviours given the already perilous state of touch-based UIs. (The inability to correctly distinguish tap vs. drag or scroll actions is one that's driven me to distraction for well over a decade.)

Unfortunately, what's at least arguable on mobile becomes the trendy fashion on desktop, which is just fucking stupid.

I have some 4k pixels of width on my desktop, and some 400 on mobile. It makes sense to not have a wide scrollbar on mobile. But it makes zero sense on desktop.

Scrollbars do two things. They let you scroll (duh), but they are also progress indicators. There are other ways of scrolling (e.g. swiping on mobile) which work by default. But there is no other default way of showing progress. I don't particularly like the progress bar example in the original post, something as unobtrusive as a percentage in the bottom right corner would work just as well. But I do want some indication of progress ...

Agreeing strongly, but I'd just like to point out that a probably more significant problem on mobile is that a scrollbar which you're likely to unintentionally hit with your fingers as you're clumsily and very imprecisely interacting with your device, or as Steve Jobs so famously declared, are "holding it wrong", absolutely is a valid reason to deprecate classic indicator-and-control scrollbars on mobile devices.

That is, a classic desktop scrollbar, dating back to Xaw widgets, the original Apple desktop, and even earlier[1] not only shows where you are within a text or display, but allows you to control where you are typically by clicking on elements of that scrollbar: the cursor, the bar itself, and the endpoint arrows. Several of these had interesting / quirky / annoying variants on interaction (those familiar with early X11 Xaw widgets can likely think of several).

There's an interesting static image comparison at Reddit:

<https://www.reddit.com/media?url=https%3A%2F%2Fi.redd.it%2Fe...>

And a much more informative interactive demonstration by Sébastien Matos from 2019:

<https://scrollbars.matoseb.com/>

Discussed on HN a year ago: <https://news.ycombinator.com/item?id=36307341>

And subject of quite a good review by The Verge: <https://www.theverge.com/2019/11/1/20943552/scroll-bar-visua...>

Another point on swiping: my mobile device for the past three years has been an e-ink tablet. And I've learnt that swiping absolutely sucks. E-ink displays are much faster than people seem to believe, but there's still lag that an emissive display lacks, and it's far better to page through a long text or display than to scroll through it. I've all but entirely adopted an e-ink optimised browser that mostly does this, EinkBro (based on FOSS Browser), and I am constantly trying to page through other apps by tapping where EinkBro's forward/back touch zones are. People who've used other ebook readers will be familiar with the general concept as most have similar features. Having to imprecisely scroll through a document or app is exceedingly painful.

Scrollbars partially solve this problem as for most, tapping above or below the cursor will advance the display by about a page of text (some feature a few percent overlap). On desktop systems, there's an even better option: the space bar. For a whole slew of apps and tools, dating back to Unix's pg, more, less, most, etc., you can page through a long text one screen at a time by tapping the space bar, which is the largest damned key (and hence the easiest-to-hit target) on the keyboard (Fitts's Law[2]).

By contrast, scrolling on mobile:

- Is highly subject to the tap-vs-drag confusion: the GUI cannot consistently distinguish a tap action (interacting with the application) with a drag (changing the viewpoint).

- Is imprecise both by contact point (that is where you're interacting with the display) and displacement amount (how far you're moving through a text or app). You might scroll by more or less than a page, and it takes considerable time for the eye to recapture the reading point.

- Obscures what it is you're interacting with. Your finger is covering the display you're trying to manipulate. A desktop mouse cursor by contrast covers little or none of the text or app.

- Is subject to further confusion based on dynamic characteristics of the document or app you're dealing with (e.g., a Web page with progressively-loaded or rendered elements, or on Mozilla Pocket, inconsistent placement and textblock wrapping around image elements).

I come to desperately hate scroll-based interfaces these days.

________________________________

Notes:

1. I wanted to claim provenance to the Mother of All Demos in ninteen-and-motherfucking-sixty-eight, but can't definitively show that Englebart included scrollbars. Wikipedia does give a 1974 implementation in Bravo: <https://en.wikipedia.org/wiki/Scrollbar#History_and_progress...>, citing <http://bitsavers.trailing-edge.com/pdf/xerox/alto/Alto_Users...> (PDF).

2. Which dates to 1954!!! <https://en.wikipedia.org/wiki/Fitts%27s_law> See also <https://doi.org/10.1037%2Fh0045689> (Fitts, 1964) and an extensive bibliography: <https://www.yorku.ca/mack/RN-Fitts_bib.htm>.

I personally like disappearing (or shrinking) scrollbars, given they appear when I scroll with a wheel, or approach towards them. It allows me to understand where I am, allows me to grab and scroll quickly when I approach them, and they allow me to see more content.

Yes, I use a big screen, but borderless and clean windows allows me to fit more content into the screen and is less distracting in general.

But this works only if you have a scroll wheel. And then it works only vertically. Horizontally you still have to click on the invisible scrollbar. To see where you are in relation to the whole document.

In Firefox, when I start to move my mouse right, vertical scroll bar appears. Same is true for horizontal one when I move my mouse down. It happens even before I get closer to any of the scroll bars. So, a wheel/trackpad is not required per se.

Moreover, almost all mice I used except the most basic ones have horizontal scrolling capability.

I'm speaking to Web browser developers.

I'm #notafan of customising site scrollbars. But I've written my own CSS to do that (used only on my own, non-public, Web pages), and man is it a breath of fucking fresh air.

There are other apps which are similarly fucked in this regard. Mozilla's Pocket comes to mind.

... not exactly.

It's possible to essentially reimplement the logic of how scrollbars look, where they are, and when they appear, in just CSS on modern browsers.

Ended up having to do part of that once because it was easier at the time than to figure out just why a mismatched browser scrollbar would show up due to complex layouting issue (in embedded world, so we didn't actually have to worry about end user preference there, otherwise I wouldn't dare use such a hack)

As much as I hate what browser devs have done to scrollbars, I tend to agree with you. The one thing worse that fucked defaults is everyone throwing their own fucked personal preferences at you. Which is why sane defaults matter so damned much.

There are browser configuration tweaks which can be done in at least some cases. On Firefox Mobile / Fennec, for example, there's a configuration hack which can be done.

I'm having trouble tracking that down but I think this might be it:

In about:config:

  ### scrollbar width
  widget.non-native-theme.scrollbar.size.override 30

  ### scrollbar shape
  widget.non-native-theme.scrollbar.style 4

From: https://old.reddit.com/r/firefox/comments/ujo1xy/how_to_incr...>

Most of these progress bars are as thin as the native scrollbars have gotten (or thinner). If these are solely a consequence to the shrinking of the scrollbar, you'd imagine that they'd actually be bigger.

I think that's a large contributing factor, but either most implementations are are as deficient [0] as what they are trying to augment or there are other things at play here. (Branding since websites haven't been able to consistently style browser scrollbars since the IE/early Firefox era; as the other comment points out, trying to counterbalance how long pages have gotten with "after-content" such as ads and comments and recommended articles and "infinite scroll" to more articles.)

[0] Or arguably worse deficient: Most of them seem to have no real accessibility themselves and are opaque to things like screen readers. Even if modern scroll bars are hidden by default and woefully tiny visually by default, they still have decades of accessibility baked in and accessible options (if you can find them).

To add to this, pages sometimes have comments or footers or other bells and whistles after the content that I’m interested in and it makes me think the post is longer than it is. This leads me to either leave the post for later or straight up close it because it’s too long.

> To add to this, pages sometimes have comments or footers or other bells and whistles after the content that I’m interested in

Or, especially in news sites, Taboola and other bottom feeder trash.

uBlock Origin's element blocker is ideal for removing those. You can define global rules for anything from Taboola, Outbrain, RevContent, etc., and never see them again.

"Sharedaddy" is another element to nuke (social link litter crap).

Whether or not either of these is user-hostile is up to interpretation and preference, but you're stating it as if it is objective fact.

You see user-hostile shrinking of the scrollbar, someone else sees more room for content and hiding something that isn't necessary until you need it. You see loading content piecemeal as hostile, someone else sees blocking that 1kb of text from being displayed while you do more network-intensive work as hostile.

To be fair, the author notes this and offers an alternative:

> One immediate thought is that this is completely superseded by the regular browser scroll bar that’s ever-present at the side of the page. However, the scroll bar could be deceiving. If your page has a comments section, the comments could make the page look dauntingly long. Similarly, references to other pages and general “footer material” count towards the scroll bar, but would not count towards the progress bar.

> Combining the two, you could imagine an always-visible table of contents that highlights the current section you’re in. With such a feature, you can always see where you are (including a rough estimate of how far into the page you’ve scrolled), and at the same time see how the current section integrates into the broader structure.

Exactly this. When you're reading different news sites, you never have any idea which sites load hundreds of comments at the bottom and which don't. What you think is a long article actually turns out to be 80% comments by page length.

The same thing happens with books that include references at the end — a print book can be 20% endnotes. I've even encountered bizarre EPUB's where for some incomprehensible reason there's a page break between each endnote, so the actual content of the book ends somewhere around the 5% mark of total page count.

I actually really appreciate a super-thin (2px) progress bar in the header.

I don't like an always-visible table of contents because I find it really distracting. But I really like the way Wikipedia does it in their app, where it's a single tap to reveal the table of contents full-screen, centered on and highlighting your current section.

That is a relevant point, although still it shouldn't be necessary; proper semantic HTML commands should allow the browser to handle it automatically (in the way subject to user preferences), e.g. the

command can be used if you want to delimit the article from the comments, and with commands such as

,

, etc you can delimit sections and automatically make a table of contents.

The browser could use this information in various ways depending on the preferences of the user. One example is the scroll bar map mode implemented in various text editors where a scaled down version of the content is shown to help you see where you are. Similarly a browser could visualize the size and location of certain elements (e.g.

and

) on the scroll bar. The key here is that it is the browser doing it so that you have a choice in wheter you want it or not on all websites.

+1 on finding progress bars distracting. I personally feel like they also "hurry" you into reading faster. If I see a progress bar, my first instinct is to try to finish as quickly as possible, even if that means a poorer understanding of the text.

>I really hate progress bars, they are incredibly distracting. One of the worst examples of front end programmers wasting their time reimplementing browser functions badly. I already have scroll bars! I do not need more scroll bars!

And the icing on the cake - as demonstrated in the quanta link - is the horizontal rendering in combination with a generous sticky wasting precious space I'd rather use for, well reading content.

> I really hate progress bars, they are incredibly distracting. One of the worst examples of front end programmers wasting their time reimplementing browser functions badly. I already have scroll bars! I do not need more scroll bars!

This is addressed though in the following paragraph (indirectly), where a table of contents is rendered on the side. (Similar is a minimap, which I like for code or complex articles, but not for long text-heavy articles.) Maybe you also hate that, but it actually serves a purpose that scrollbar can never replicate and is much more useful than a scrollbar for many people.

Funny, I quite like progress bars! I agree that they can be too bold at times, but it's nice to have a visual indicator since scroll bars have disappeared (especially on mobile).

> I really hate progress bars, they are incredibly distracting. One of the worst examples of front end programmers wasting their time reimplementing browser functions badly. I already have scroll bars! I do not need more scroll bars!

I'm just really glad that we seem to have mostly moved past headers that expand down in front of the content you're trying to read as you scroll down the screen. I can't think of a single justifiable reason for this behavior, but it was all the rage for a while. Also, I suspect the progress bars resurged because browsers became enamored with invisible or barely-visible scroll bars.

One micro feature I implement on my blog that I would like to see everywhere: a single-page index of all the posts, like at https://blog.zorinaq.com

Don't paginate this. I want to see at a glance the titles of all the posts the author wrote. I want to be able to ctrl-f to search these titles. Heck, even if you had 100k titles they could still easily be shown on one page, as it would compress to 1 or 2MB transmitted on the wire which is still more lightweight than the average web page size.

Yes please!

Another reason: I'll often come across a blog post from 12 years where the author writes "in my next post, I'll continue to discuss..."

And how the heck am I supposed to find that next post? They didn't add a hyperlink, obviously, because they hadn't written it yet. Sometimes a blog has posts you can navigate by month, but that's definitely a small minority of blogs I come across.

If there was just a single-page index, I could Ctrl+F the title of the current article, and quickly see what followed it chronologically.

> Another reason: I'll often come across a blog post from 12 years where the author writes "in my next post, I'll continue to discuss..."

Worse than that is the "part 3" blog post, where the opening paragraph of part 3 starts out with something like:

In part 1 we discussed "...one or two sentences on part 1..." and in part 2 we discussed "...part 2 quick overview..." ...

And there are no links at all in part 3 to either of parts 1 or 2 (yet, presumably, part 3 was written after parts 1 and 2, so links back to 1 and 2 could have been inserted). If one came across part 3 from a search, and landed on it for the first time, one just might want to start at part 1 and read forward.

> Subscribe to the blog's RSS feed?

Which has the 10 or 20 most recent posts, but not the post from 12 years ago. If it's a wordpress blog, you can use pagination tricks to get older posts, but, AFAIK, there's no standard way to say "Give me all of the posts" when fetching the RSS feed.

These days an awful lot of blogs don't have RSS feeds.

Especially blogs that are part of broader news publications, in my experience.

But yes you're right when there is a feed you can open that in Chrome and Ctrl+F, at least.

(Obviously my complaints come from blogs that don't have this. But also, opening an XML file isn't exactly user-friendly, and 99% of end users would never know to do it.)

But is it a blog if it doesn't have an RSS feed?

…okay sure, technically yes, but not one I will be able to follow, or remember to read until it pops up in someone else's aggregator or links in the future.

Sadly, sitemaps aren't usually much help because:

- They're often only URL's which may not have titles or dates at all

- They're often not in any particular order (there's no reason for them to be chronological, so they frequently aren't)

- They're often paginated as well, where sitemap.xml just refers to multiple pages, so you can't Ctrl+F on a single page anyways

- You don't get one per-blog if there are multiple blogs on a domain

- You get all the other junk from the rest of a site if it's a blog that's part of a larger site

I recently added a search feature to my site. I almost cracked open the Algolia docs … and then I just wrote a 4-line form …

▷

…and now DDG just does it for me. Zero cost, zero hassle.

So that.

I mean, just make sure that your blog is easily consumed by any web search engine.

And in addition to the full non-paginated index, I also have a full non-paginated tags page. Like categories, but with pages showing multiple times if they have multiple tags.

https://blog.pwkf.org/tags.html

My pet feature I'll try to add is sidenotes. It does annoys me to jump back and forth to read them. Even as a popup (wikipedia style), it is still intrusive...

It's comforting to see blogging as a topic on HN front page, along with plenty of constructive comments. I'll take some of the ideas on board.

I've been working on a blogging service myself (here's my blog on it https://lmno.lol/alvaro), focusing on minimalism, hopefully enabling the content to shine on any kind of device (you can read from your favorite terminal too).

You drag and drop your entire blog from a markdown file https://indieweb.social/@xenodium/112265481282475542 (feels more like keeping notes, which you happen to export as a blog).

Service hasn't officially launched. You can play with https://lmno.lol (ephemeral posts) without signing up. Reach out if you'd like to register a blog (invite at lmno.lol).

ps. ASCII art is not displaying properly on Android (known issue). So far, I can only fix by including a monospace font. I'd love to know if this is still possible to fix using system fonts.

Nice list! I like many of these "microfeatures" too. Some I have on my site (https://evalapply.org), some I don't because I don't want to require Javascript for blog functionality. I think I have a few others not in that list.

This is my set of "microfeatures", which are all available in the post I linked below [1].

- All posts must have title, summary, dates (published, updated), one tag at least, and hot link to top of post (it's always #main)

- Open graph metadata for all pages (title + summary)

- All first-party content must be accessible as plain HTML

- Typography and separator elements to establish structure and distinguish functionally different areas of content

- In-page navigation (especially jump links to and from footnotes)

- Table of contents when needed, in a disclosure element

- Custom navigation to group a series of posts

- Markers for external links

- Captions for images and embeds

- Disclosure elements for extra context

- Footnotes (with links back to the referring text)

- Index pages with summaries (the main blog index, and each tag's index)

- RSS feed (global)

So far I'm reasonably happy with things as they are. At some point I'd like to participate in a webring.

[1] https://www.evalapply.org/posts/emerging-from-dotemacs-bankr...

(edit: typo, and a point I forgot)

On the web, I like footnotes more provided they link back to the referencing text. On my blog, I love to use footnotes for little tangents and asides, apart from their usual task of providing references. Not every post/article needs them.

Sidenotes are cool, but they are a skeuomorphism not amenable to fluid layouts. I feel plain vanilla in-line disclosure elements work better, and they might be better for accessibility too.

In dead tree books, I enjoy both. Marginalia can elevate the text. Footnotes are always in context of the whole page, which I can view all at once. No scrolling needed.

Sidenotes can't be on the side on a small screen. You have to put them in between paragraphs, at which point they stop being sidenotes and just become part of the text. Then, how do you handle them in your RSS feed? What happens if the reader clicks on the reader view button in their browser?

Footnotes always remain footnotes, regardless of all of that.

Link previews don't really work on mobile. Also they just create UI land mines. If I mouse over some area of the page I have unexpected content jump up. If a link preview hits the external link that's also potentially leaking traffic or tracking data from me.

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.

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?

Agree.

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.

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.

The microfeature I like is when posts have the full date. Blog authors want their content to be evergreen so they try to exclude it. Context is essential for me to interpret the perspective, especially for technical content. I end up having to go to the internet archive to see an estimate of when they wrote it anyway.

Almost all of these are pretty nice. I disagree with the preview-on-hover though. That sends off a request to a possibly unknown (possibly unwanted) destination. I often hover a link to look at what the URL popup says in the bottom corner, before following it. It's just not a very privacy-conscious feature, even if convenient.

With modern Content Security Policy restrictions and such most sites now have, previews almost entirely have to be implemented server side to make them work anyway, so no real privacy fears.

I've seen link preview solutions start to appear that I would assume are doing some basic moderation and logic to ensure consistency. I've recently seen on product hunt - Linkz.ai link previews SaaS .

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.

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.

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.

But that's not the reality of the modern web.

And it doesn't do much good to pine for the past.

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.

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.

No thanks. I'll stick to RSS.

> 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.

It still exists, even if it is not used as much these days.

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.)

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.

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.

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.

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.

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.

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.

Since this article mention's Gwern's site several times:

While I admire Gwern's work a lot, I often find his website is trying to do so much that my browser will really struggle. Especially on mobile. It's bad enough I usually avoid reading there, which is a shame.

I'm not sure exactly what causes it, but it might be a combination of page length with many layers of nested, richly formatted and embedded content.

> While I admire Gwern's work a lot, I often find his website is trying to do so much that my browser will really struggle.

As a web developer, I often look at the HTML and CSS of interesting websites…

I gotta say, I've never seen anything quite like https://gwern.net.

It's an impressive looking site IMHO; but pretty much everything he's done is very user hostile and wasteful of the user's resources, like downloading 14 fonts.

He's doing everything you're not supposed to do if you care about your users or performance in general.

Every page is pretty much like this.

From cssstats.com:

Rules: 1,484

Selectors: 1,757

Declarations: 3,914

Properties: 243

Total Selectors by Type

Selectors are the part of a CSS ruleset that describes what elements in a document the rule will match.

ID: 534

Class: 1,516

Pseudo Class: 296

Pseudo Element: 382

It just goes on and on like this.

Ditto. I like Gwern's content but not much the presentation. The same goes for Simon Willison's site.

I much prefer the brutalist look of Drew Devault, Fabien Sanglard, or Dan Luu's site.

The "danluu layout" takes minimalism too far in my opinion, and getting in and out of some readability mode can be slow/annoying.

Just a lil bit of padding here and there could improve the presentation a lot, but I'm guessing the author consider this design kind of a trademark by now.

I don't mind Drew or Fabien's layout, which have a reasonable column width. But Dan's site is unreadable for me (at least on desktop) without reader mode. What would be the reason for choosing to have full-width text on a blog?

Dan's website is a great example of the pendulum swinging in the other direction to malicious non-conformism. Yes, UXers have made modern web design hell, but presenting a raw unstyled html isn't respecting your user much either.

I think that is not so simple to solve. Limit it to some column width? Someone will complain that it only uses one third of their screen. Unlimited width? Someone will complain about whole width text. But the good thing is, that there is reader mode and evem if there wasn't, you could zoom in or resize the browser window or send to new window and resoze only that.

Yeah, most browsers do have reader mode now. I honestly don't love them because they're typically not customizable, and are sometimes too narrow for my taste.

I wouldn't mind resizing the browser window except that with tabbed systems that means you're resizing all of the tabs at the same time.

I tend to think that if you make the width something in the neighborhood of what the NYT, Medium, or other well-known sites use, people won't complain. But I could be wrong!

Yeah, it used to be fast, but then you add features and have pages with a ridiculous amount of stuff in them compared to most pages (every DOM element costs you), and, well...

We plan to go back and optimize stuff once one last feature is in. (It's a novel feature I came up with I've never seen anywhere else: I call it the 'browsing history' feature. Every link you pop up will also be transcluded into a section at the end, so you can create your own bibliography as you go. This means you don't have to have FOMO about reading every popup or tab as you go, and you can rebrowse what might be interesting at the end, or even snapshot the page with a particular set of links having been browsed.)

Achmiz meant to get around to it a while ago but among other things, he got nerdsniped by studying high-dimensional geometry for modeling an extradimensional invasion in his current D&D campaign: https://blog.obormot.net/Extreme-D-D-DIY-adventures-in-hyper...

I don't like side notes. It tries to separate the readers to two groups---one who wants more details and the other who doesn't, but the problem is that there's no such natural division.

When I read articles with side notes, I often find myself constantly checking the side notes and then regret doing it because the info is unnecessary. I prefer the author to carefully think through and choose what info to present instead of just dumping info to the side notes.

I think that just means the author is writing bad side notes. Structurally, they do have a place. You said that yourself - "I do like to see details and I'm curious". An author moving all their side notes into the main content would not make it clearer. An author deleting their useless side notes would make it clearer. Neither of those speak to the usefulness of side notes.

I use them a lot on allaboutberlin.com, because some readers are familiar with certain things and others are not. This lets me serve both audiences while keeping the guides short and straightforward.

I very rarely use footnotes except for citations, unless it's a precision that would be useless to all but the most erudite readers.

I treat sidenotes/footnotes like parenthetical expressions - too many are distracting. A strong writer should be able to convey his thoughts and asides without interrupting the flow of text.

But I'm not sure they can be eliminated entirely. At least sidenotes make use of empty space on wide screens.

The thing is, I do like to see details and I'm curious. That's why I check them in the first place. But we can't know beforehand whether it's useful or not.

This is true for both footnote and side note, but for footnotes I can give it a glance to see if I want to read it thoroughly after reading the whole page, whereas for side notes, they are so easy and tempting to be seen. I feel the point of notes is that they do not interrupt the main flow but side notes put them on almost equal footing in terms of attracting attention as the main content.

Besides, footnote/side notes should be kept minimal, otherwise the note becomes the main content. I find articles with side notes often overuse them. Yeah, if they are kept minimal I guess both approaches are fine.

> otherwise the note becomes the main content.

There are some authors whose footnotes (even sometimes indices) I read before the main content, because in the past they've hidden all the best bits there.

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.

I like most of these, but I'm on the fence about Link Preview. I find it gets in the way as often as it helps me. I end up triggering it by accident quite a bit, and especially the wikipedia version where there's no X in the corner to dismiss the preview can become annoying. The footnote pop-up bubble on substack can have the same problem.

On a slow and unreliable connection, it's also one more thing that I wish had a toggle to turn off.

Related to this, something I consider an anti-feature: any form of messing with a link to a different page that results in Control+Click not opening a new tab. Bonus negative points if you've scripted it to redirect the page in the current tab and there's no very good reason for it to be a single-page application (draw.io has a reason, the average blog does not).

Table of contents is the feature that, in my opinion, ought to be implemented as a part of the web browser instead of within the document (I was told that Dillo apparently did at one time (but no longer does, although I suggested to them to add it again), and it is commonly implemented in Gemini browsers, though). This would also be true of page progress, linkable headings (the document author would need to give it a ID, although the browser should then handle the rest), link preview, and markers for external links. This should also be true of fonts and colours, too; the document author should not need to specify them. Some of the other things they mention, are things that would be helpful for the document author to handle, though.

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.

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.

> 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.

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.

Feels like many of these features should just be built into the browser. Why can’t the browser assemble a table of contents based on header hierarchy? Isn’t that the point of the number in h1-h6? Why aren’t elements with ids easy to link to by default? Add a “copy-link-to” to the standard context menu in the browser. Etc.

It feels like browsers over the decades have moved away from catering to power users.

Is something like Arc moving back? Without having used it (I plan to at some point), I've heard that at least its tab management seems catered towards "professional browser users".

I like the way Cory Doctorow puts it in this piece:

> A web browser that's a "user agent" is a comforting thought. An agent's job is to serve you and your interests. When you tell it to fetch a web-page, your agent should figure out how to get that page, make sense of the code that's embedded in it, and render the page in a way that represents its best guess of how you'd like the page seen.

https://pluralistic.net/2024/05/07/treacherous-computing/#re...

interesting take from an academic practitioner who also runs a blog.

i find it fascinating though in terms of how tech literate folks from outside this space is changing the way they consume written (web) content.

from the llm-chat paradigm shift, most people are less likely to read the source material, if this was not already the case thanks to tiktok and google search summarization. while i might feel that most people outside of hn were not reading personal blogs anyways, how many would truly appreciate these quality-of-life features.

One site I like a lot is https://mriquestions.com/index.html

It has a really interesting navigation where there's an article, links to related articles, and references etc.

Part of what I really like about it is the format of having the main text and then an "Advanced Discussion" accordion at the bottom that can be folded out for more detail. It's not uniformly used across all pages but I do like the format a lot. It's sort of an alternative to sidenotes but less disjoint where it treats the first part of a page as the intro and then expands in detail directions. It lets the intro be a higher-level and then "corrected" below.

Example (just one I found, there are better ones but not all pages have them):

https://mriquestions.com/how-to-reduce-sar.html

Anyway just chiming in that it's a microfeature that I like vs say wikipedia which can just be... massively overwhelming on some pages.

I don't necessarily think this feature is fully realized at mriquestions, but the MRI field suffers from multiple audiences (radiologists, technologists, engineers, etc) and its really difficult to pull content together that foster communication between these groups. mriquestions is by a radiologist so its a bit lacking on the engineering details side but its still pretty good but higher-level technologists use it well to get beyond the lies we tell them. It doesn't really get too far into the lies we tell radiologists though but sometimes it gets close (by lies I mean oversimplifications) and usually the references are good for the technical details.

> Links to Other Sites

I used openring-rs for my Astro [1] site, but eventually replaced it with a TypeScript-native solution [0]. You can see it on my blog, e.g. at the bottom of this link [2].

If you're looking for an easy way to pull RSS feeds from TypeScript and show the N most recent posts, take a look at my library.

PS: I'm currently unemployed, so if you have any feature requests I will quickly oblige :)

PPS: if you haven't heard of Astro [1], do yourself a favor and check it out. You write JSX syntax and get static HTML/CSS out, with the option for JS only as needed.

[0]: https://github.com/shepherdjerred/webring

[1]: https://astro.build/

[2]: https://sjer.red/blog/til/2024-06-05/

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.

RedSails.org has a lot of very nice micro-features:

* Tastefully displays the most relevant citation at the bottom of the screen as you read, e.g. see https://redsails.org/really-existing-fascism/

* Uses system light/dark UI settings.

* Literally every article (with descriptions, author info, post date, etc) displayed on the homepage in chronological order with no pagination, great for ctrl-f, etc.

* Selected authors and category-based navigation available.

* Entire site is very fast and lightweight, text-focused, no superfluous javascript or CSS, good typography, works well on mobile, etc.

* First-class RSS feed support

The idea is great, though I think I personally would prefer for this to happen on the server side (during rendering a static site, perhaps), not in the user's browsers. Particularly if the user doesn't enable JS, or has a slow connection.

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.

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.

It is an interesting format, but a bit hard to discover. If it would not have been for your comment, it would not have occurred to me, that there is a second level which enriches the overall topic.

Is it essential to the format to open all secondary parts at once? Otherwise that would be a great use case for the details/summary tag, which also would come with affordances that indicate that there is more information available.

Thanks for that feedback - I will think about how to make the parts beyond the tip of the iceberg more obvious and discoverable. Philosophically, I want the "tip" to be as uncluttered as possible but ... we'll see what I can come up with.

Theoretically, if enough people began writing in this form it would then become obvious by virtue of familiarity ...

Most of these ux enhancements should be browser addons, in my view. We have gone way beyond what a website should be responsible for versus what’s up to the reader experience to implement.

I agree; the website should not need to be responsible for most of this stuff (and even when it is, the way it works is too messy). (In some cases the document author would still need to specify, e.g. the IDs of headings so that they can be referred to in URLs, but the browser should handle the rest; the author should not also need to add links in the headers.) The table of contents might even be suitable as a built-in feature. Having a progress indicator for only the article and not comments would be possible by using the standard

command; a browser might choose to (subject to user settings) display a progress bar or scroll bar for the article only. The user can disable the features that they do not want (and/or change the features that they want differently). (Some people will use other file formats and protocols to try to improve this; and, if you like to do, you can even make available multiple protocols and file formats)

I really like "archive" and "tag" overviews. I don't want to scroll through every post in full as a way of finding an entry that interests me. Not really a blog but Hackaday on mobile is really bad at this. It's kind of hard to filter for interesting stuff without having something specific to search for.

While I heartily agree with nearly all of the suggestions here - particularly ToC and Code Blocks With Origin (which I really should implement on my own website) - FWIW, I disagree on the need for Progress Bars and Dialogues.

Progress Bars seem like an eyesore to me, a distracting visual feature that's trying to goad me into finishing the article. As other commenters mentioned, the browser already has a scroll bar, which indicates the amount of content I have read. A progress bar just seems unnecessary.

As for dialogues - while they can be cute and interesting if done well, it usually just gets in the way of the content I'm trying to read. The problem that it solves - "ask[ing] questions from a less-experienced point of view" - can often be accomplished with regular prose instead eg. "But you might be asking..."

A feature that I'd like to see in more blogs is a 'Tech Stack' page[0]. I've often stumbled on websites that look very appealing, but have no description of how they were created. This page would describe the technologies and tools you use to write your website. Things like static site generators, CSS, JS framework (if any) could go in here.

I'd also like to add 'Site Maps'[1] to this, which I've implemented as a list of all articles on my website.

[0]: I have such a page at https://twomorecents.org/tech-stack.html

[1]: Looks like this has already been mentioned: https://news.ycombinator.com/item?id=40778888

> Easily Linkable Headings

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.

Try this.

/* 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).

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).

There was a post on here recently to a blog that had a multi player cursor, so you could see other user's cursor positions and type wee notes - wish I'd taken note of it because there was a photography exhibition in the V&A where 12 hours of footage of London had been commented over in a similar way, and they were replaying it - "this guy will trip soon" and "she's texting the guy over there and he's said no"

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.

But yes, the scrollbar ought to be enough.

If you have a blogroll, update it regularly. I get that blogs are passe (that's why I started one a while ago). It is annoying to go to one of the few active blogs and find that most of the blogroll links go to sites not updated in a decade or expired altogether.

This is a good list. Have you reviewed any blogging systems to see how many of these features they contain (in a comparison table for example)?

What if there were a standard object that everybody rendered to their taste? To some, these are nice features, to others it's just bloat that causes a 5mb download for 1kb of text.

Yes, although HTML is rather messy. It is why some people use Gopher, had made up Gemini and Scorpion file formats too. (You can also serve multiple protocols and file formats if you want to do.)

A well-formatted table of contents nearly always ensures I won't be reading blog spam.

I use them for my annual book review posts. No idea if anyone ever uses them, but damn are they pretty to look at.

More nice features:

- 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

- inlining css, js, and svgs so it can be saved as a single html file

Or just use http2 and have a much better organized code without need to build/bundle them together.

My most important microfeature is center-aligned pages. Whenever I read something on a large screen and the content is left-aligned, leaving a large gap on the right, it really turns me off.

I try to make [mine](https://rednafi.com) center aligned on all clients.

> Whenever I read something on a large screen and the content is left-aligned, leaving a large gap on the right, it really turns me off.

I’m curious, why do you find that an annoying? The alternative you’re advocating is ostensibly just shifting half that gap to the other side.

If I were to be fussy about the gap then I’d be more interested if they were a layout that could make use of that space rather than alignment. The example in that article about side notes is a great example of utilising otherwise redundant space on larger screens.

Ah the push and pull. In the beginning, scroll bars were a feature. Then proportional scroll bars were a major development. Then scroll bars were dynamic, auto-hiding, optional, or removed altogether. So designers put progress bars across the top of individual pages--some sites have them, most don't, all different ad-hoc implementations. It's a new feature all over again, going through the cycle of learning what works and what doesn't. People hate it. People love it. All this has happened before. All this will happen again.

Hot take, but the microfeature I love in blogs and websites is a date at the very top. I know patio11's points against it, but from a user perspective it just adds so much context that for me it's a no-brainer.

I hadn't heard of patio11's points against it. So I looked it up.

https://training.kalzumeus.com/newsletters/archive/content-m...

Is this the man responsible for the popularity of dateless blogs? (I tried to check the date on the post but... alas! ;)

Just kidding, we still have the Internet Archive (for now) so I am able to get the same information ("2014") in a much less convenient way... (I suppose my willingness to do so removes me from the category "most readers?" Though that will depend on the blog!)

The argument seems to be "people will disregard the information in an article if they think it's old." I can't speak for other people, but I actually find the opposite is true. The older a post, the more likely I am to find it interesting, and take it seriously.

Same idea as this, really: https://xkcd.com/2634/

>>What does the red line through HTTPS mean?

>Oh, just that the site hasn't been updated since 2015 or so.

>And since it's been around that long, it's probably legit.

This is a really great list (well, maybe not link previews, but everything else).

Sidenotes in particular are something I want to see basically everywhere, not just blogs. Modern screens have tons of horizontal space, text is most readable in pretty fairly narrow columns anyway, and scrolling to the bottom just to read a footnote (or, worse, having it pop up in some janky pop-over) is really unpleasant. Happy to see them catch on the blog world at least.

I do not get why people are sceptical about link previews. When done right (without iframes), e.g. in Obsidian or via Linkz.ai , they actually add value.

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?

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.

> On Apple platforms, they hide the scrollbar unless you’re scrolling.

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.

Well, but it is visible when you scroll.

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)

> (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.

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).

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.

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.

（评论） (comments)

,

, etc you can delimit sections and automatically make a table of contents.

（评论）
(comments)