I achieved something similar for my site by putting the HTML file generated every few minutes on a single S3 bucket and putting CloudFlare in front with caching page rule on the HTML too (by default HTML is not cached by CF).
To be devil's advocate, I feel like those serif fonts were easier to read on a low resolution monitor because they were sharper due to the pixels being very apparent.
Here not even on a 4K, I find it difficult to read the headlines.
Maybe it's just because the colour scheme somehow makes it less interesting.
Also, I was hoping that 68k.news supported HTTP 1.0, but it doesn't, it's a virtual host on the IP, so needs the host: header variable set, which is HTTP 1.1 - that's a bit of a shame as it means the original browsers such as Mosaic can't access it.
Some articles are actually... 8 sentences. That is it. How on earth does it then take 10 seconds to scroll and parse all the fake inserts to finally realize that this is a poorly researched snippet masquerading as news...
This part of the web makes me so jaded about 'progress' I'm into woodworking now.
In an attempt to enjoy this effect more broadly, I have Reader Mode set to enabled by default on Safari mobile.
On Firefox desktop I often use the Reader View button on news stories. There is an extension to enable this by default, but I have a hard time trusting browser add-ons.
its pretty great.
I didn't know you can do that, thank you!
A successful Example
http://68k.news/article.php?loc=US&a=https://news.google.com...
I feel so incredibly fortunate to have been old enough to see and understand the start of all of this, and later, to be a part of all of it.
Compare this bookmarklet: https://www.masswerk.at/bookmarklets/netscapify/
Argh. Hoping "Godzilla vs Kong" reviews were going to be better. When will Hollywood learn the secret to a good kaiju film = less humans, more monsters ;)
Funny that an emulated Mac hates Safari.
Second impression: instinctively tries scrolling with trackpad _help why isn't it working_
This really made my day, thank you for sharing it.
Edit: also it shows a few key news articles with related articles. This means I'm not infinitely scrolling which is nice.
Readability to parse the content. SimplePie to fetch the data (I assume). Dat from RSS feeds?
In case you want to make something similar, I recently wrote a blog on where you could get news data for free [1]
(self-promo) I'd recommend to take a look at my Python package to mine news data from Google News [2]. Also, in 3 days we're releasing an absolutely free News API [3] that will support ~50-100k top stories per day.
[1] https://blog.newscatcherapi.com/an-ultimate-list-of-open-sou...
[0] https://www.theregister.com/2021/03/29/google_news_netscape_...
> On a technical level, the site obtains stories through the existing Google News RSS feed, which are then processed with some PHP trickery. "Google News has a very nice RSS feed, for each topic, language and country. So I thought I could connect to that feed, and write some code to simplify the result way down to extremely basic HTML, targeting only tags available in the HTML 2.0 specification from 1995," said Malseed.
> "So I used a PHP library called SimplePie to import the feed, and wrote some PHP code to simplify the results into a nice front page, using Netscape 2.0.2 on my 1989 Mac SE/30 to make sure it loaded fast and looked nice. The articles were a little more difficult, because they are on all sorts of different news sites with different formatting.
> "So I found that Mozilla has an open-source library called Readability, which is what powers Firefox's reader mode. I used the PHP port of this, and then wrote a proxy that renders articles through Readability, and then I added some code to strip the results down even further to extremely basic HTML."
Best viewed on mobile and you can optionally use a version without images by clicking the link at the top right of the page.
Let me know if you have some time
I should make it an option for my own site, and I will! Thank you for the inspiration.
Google news rss seems to be different and is full with amp links:
(Also, I thought every page from that era was required to have at least one <blink> tag, and possibly an "Under Construction" image.)
I've come to realise that most online commercial publishing does not even use bold within body text, giving another filter trigger for stripping cruft.
Far easier to read since the length of the line is absolutely perfect. Pro tip: https://practicaltypography.com/line-length.html
That said - something is wrong with NPR, a bunch of Lorem Ipsum links :)
I recently fixed up an old 486 I purchased off eBay but it was bittersweet when I managed to get it connected to the 'net. Most websites were inaccessible due to the lack of support for today's encryption protocols, those that were had numerous JavaScript issues.
Edit: there was no CSS support in 1.1 :)
Like, part of the premise of CSS was progressive enhancement, where just the semantic structure alone would provide an adequate experience with however the browser might choose to render those elements by default. Basically my question is, if the font size tags were taken out and just bare h3/h4/p used instead, would that still render a usable page on Netscape 1.1? Could you then supply font overrides via a <style> tag in the header which could be applied by later browsers?
Obviously it would be a different kind of experiment as the result would no longer be identical across all the "supported" browsers, but might be an interesting comparison point.
It's surprisingly tractable to plug 90s machines into the internet via ethernet adapters or little serial gadgets that can do SLIP or pretend to be hayes modems, but the modern web full of crypto and execution environments that can bring modern computers to their knees is not kind to them.
Newspapers went through the same thing. The older papers are all stories and were funded through the price of the paper, then ads invaded the margins.
I assure you 19th Century newspapers had advertisements.
For example:
https://chroniclingamerica.loc.gov/lccn/sn86072192/1897-08-0...
And an 18th Century newspaper with advertisements:
https://chroniclingamerica.loc.gov/lccn/sn83021183/1777-03-0...
How far back do you go to find newspapers with no advertisements?
You may also like http://lite.cnn.com/en
It's so refreshing to have pages load instantly. Websites get so bogged down with loading resources from 12 different places. It'd be nice if a static webpage was the default and every change that slowed down loading was explicitly laid out to stakeholders in terms of marginal load time and resources required.
The main list could have dates and times and categories, so it's not just a dump of text links.
Each article could have a reasonably sized image or two without compromising the load speed.
Finally, a single "sponsored by" link could be included in the page to provide revenue via advertising.
It's insane that media companies feel that their sites need to be a bloated mess or barely there, and nothing in between.
Regardless, the fact that the URL isn't served via https is an indicator to me the this is a forgotten service and will eventually disappear the next time CNN does an overhaul of its web servers.
This is another reason I like AMP in general, despite all of its issues, it generally is much cleaner [1] than the non-amp alternatives [2]
https://txtify.it/https://www.nytimes.com/2021/03/29/nyregio...
Now how do I automate this? Maybe a simple bookmarklet?
If you paste:
var url = document.URL ; var title = document.title ; window.location.href = "https://txtify.it/" + document.URL;
into: https://caiorss.github.io/bookmarklet-maker/
Then drag the bookmarklet to the bookmarks bar, you've got a one-click textify option :)
Please refer:
<font size="5" color="#9400d3">
The <table> layouts are definitely not missed by me.
Given their well-publicized insistence on building for a ton of obscure arches, I'd expect you could run modern Debian on such a machine no problem, with a modern web browser. Might be a little slow, especially if you stick with the original disk, but should be perfectly usable.
Nope. Current builds of i386 Debian require a Pentium Pro or later -- I believe it's because they're compiled with the CMOV instruction, which wasn't present in the Pentium or earlier.
Linux might be a whole other battle to get working but might be a fun project to attempt.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 2.0//EN">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<html>
<html>Nitpick 2: <meta> goes inside <html> (inside <head>, really).
Nitpick 3: The <meta> tag is only a band-aid for shitty webhosting where you cannot access the webserver config to make it send the correct Content-Type in the actual HTTP response headers. The modern <!DOCTYPE html> instead implies a default of UTF-8 which works well for most.
<!DOCTYPE html>
<html>
> The Encoding standard requires use of the UTF-8 character encoding and requires use of the "utf-8" encoding label to identify it... If an HTML document does not start with a BOM, and its encoding is not explicitly given by Content-Type metadata, and the document is not an iframe srcdoc document, then the encoding must be specified using a meta element with a charset attribute or a meta element with an http-equiv attribute in the Encoding declaration state.
<https://html.spec.whatwg.org/multipage/semantics.html#charac...>
The same articles would seem longer in print because they're formatted in such narrow columns, wrapping around images. There's some thought that goes into the layout.
Of course, the internet breaks that particular illusion. And I'm sure that if a marketing department could do to their printed paper what they do to their website, design and readability be damned, they would jump at the chance.
link: <https://txtify.it/dark.css>; rel="stylesheet"
But I think you can just do <html> nowadays and it empirically just works. Seriously, screw the anti-DRY people that want me to put some !DOCTYPE or xmlns tags with some W3C links or some DTD nonsense inside ... I should only have to specify "html" exactly once, no more.
If I had designed the spec I would have just made it
<html version="4.0">
<html version="5.0">
<html version="5.1">
This is a valid HTML5 document:
<!doctype html>
<title>This is valid!</title>
<p>Really, it's valid!
E.g., this is the entire code of Netscape's first home page:
<TITLE>Welcome to Mosaic Communications Corporation!</TITLE>
<CENTER>
<A HREF="MCOM/index2.html"><IMG SRC="MCOM/images/mcomwelcome1.gif" BORDER=1></A>
<H3>
<A HREF="MCOM/index2.html">Click on the Image or here to advance</A>
</H3>
</CENTER>
"margin-left:auto;margin-right:auto;" what the F???
"width:500px;margin-left:-250px;left:50%;" what the #$#$@?
Are they kidding?
"Don't use tables, use CSS!" was a big message. But CSS's tools for tabular layout were extremely poor and difficult to use, leading to much frustration. It was a joke how hard it was to create a simple responsive three column layout in CSS, a thing easily accomplished with tables and very common on the web. Getting that three column layout right seemed like black magic in CSS1.
It was, but in hindsight maybe the message needed to be elaborated more. Perhaps it should've been "Don't use tables for layout, use CSS!"
Besides that, CSS IMO accelerated more complex and visually pleasing websites, and arguably spurned on the Web 2.0 look. Unfortunately, due to the message not specifying the for layout bit, it took a while for many devs to unlearn that tables are bad – tables aren't, they should just be used for tabular data.