Thanks for the link. Technical part from that interview:
> 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."
"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.
I feel quite the opposite now, a table feels like so much typing compared to a quick flexbox layout. Even when I legitimately need a table, I dread it.
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.
But this was exactly the problem. They said "don't use tables", but then didn't have anything that could do what you could do easily with tables. Instead you got many hours of arcane and confusing combinations of float: and clear: tags. Especially if you were trying to avoid absolute positioning and wanted the page to be responsive.
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.
At the same time, it's interesting to see those tags used for what otherwise looks like a pretty un-styled page.
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.
Looks fine? It is a big blob of undistinguished text. If you squint your eyes everything looks the same. The lack of column widths means your eyes have to do a lot of scanning especially on a bigger/wider screen. The lack of color/font/size differentiation means there's almost no information hierarchy to it. While we all might complain about advertisements and loading times, I for one are very glad we have moved on so significantly.
Great! For even better results, please, set the background-color to `#C0C0C0`. (Netscape default. However, I'm not sure, if this was also the default on Windows, as well.)
Agreed. Blue text on white background is jarring. And I was wondering what the original Netscape Grey was!
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 ;)
Subjective, but I wonder if browsers had defaulted to sans serif font instead of serif, people wouldn't complain about "how bad this webpage looks". I get the document origins of course.
I'm curious where the data get fetched from. The Author mentions that Mozilla Readability and SimplePie are used.
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.
It would be great to get this working on each of our personalized Google News feed. But I suspect it would require either a userscript stylesheet or Google sign-in (if that even gives you a personalized feed).
Viewing the source of that webpage really takes you back. Plain old HTML. It's nostalgic beauty.
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.
Oh I actually quoted the website's source. They have that DTD meta crap in there.
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
Incredibly more readable, and memorizable. A markup language (literally), by virtue of being a markup language, should not be impossible to memorize. Making scary strings like "-//W3C///DTD" part of the spec is counterproductive.
That's SGML tag inference at work (theoretically at least, since browsers have HTML parsing rules hardcoded). SGML knows, by the DOCTYPE declaration, that the document must start with an "html" element, so it infers it if it isn't there. Next, by the content model declared for the "html" element (normally obtained via the ugly public identifier that sibling comments complain about), a "head" element is expected, so SGML infers it as well if it's declared omissible, and so on.
In the "old days", web pages were often just the bare content (no html, head, body containers, no DOCTYPE declaration). A few sites also featured just the body tag (and respective content) for setting the background attribute for the page background color.
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>
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.
Nitpick nitpick: the html doctype doesn't imply UTF-8. Valid modern HTML documents must be encoded using UTF-8, but the standard also requires that the encoding be specified somehow.
> 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.
Were you just using the browser/OS it came with, I guess like Windows 3.1 or 95?
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.
> I'd expect you could run modern Debian on such a machine no problem...
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.
Ah, good point. Looks like Debian Jessie might have worked for it? In any case, distrowatch suggests a few others like Alpine and TinyCore that might have the proper support.
I'm going to hazard a guess, that because ancient browsers sometimes displayed html tags they didn't understand, the author has deployed a hack to ensure the correct character encoding is used on a new browsers without soiling the rendering on older systems.
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.
143 comments
[ 2.9 ms ] story [ 84.9 ms ] thread[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."
Edit: there was no CSS support in 1.1 :)
"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.
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.
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.
https://en.wikipedia.org/wiki/Links_(web_browser)
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 ;)
Google news rss seems to be different and is full with amp links:
https://news.google.com/rss?hl=en-US&gl=US&ceid=US:en
https://text.npr.org/
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 :)
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...
[2] https://github.com/kotartemiy/pygooglenews
[3] https://newscatcherapi.com/free-news-api
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.
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
Incredibly more readable, and memorizable. A markup language (literally), by virtue of being a markup language, should not be impossible to memorize. Making scary strings like "-//W3C///DTD" part of the spec is counterproductive.This is a valid HTML5 document:
Paste it into the validator yourself if you don't believe me: <https://validator.w3.org/nu/#textarea>E.g., this is the entire code of Netscape's first home page:
http://home.mcom.com/"margin-left:auto;margin-right:auto;" what the F???
"width:500px;margin-left:-250px;left:50%;" what the #$#$@?
Are they kidding?
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.
> 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 <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.
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.
Second impression: instinctively tries scrolling with trackpad _help why isn't it working_
This really made my day, thank you for sharing it.
Funny that an emulated Mac hates Safari.
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