My first, knee-jerk reaction was “God, that loaded fast!” even though I already knew going in what to expect.
Text-only doesn’t have to be _ugly_ though. Once you embrace minimalism, you realize that aesthetics are primarily a concept of white space and typography. And neither one of those interferes with text only, thank god.
While modern CSS has been inching towards becoming Turing complete (is it already now? I think so long as adding html elements via :before/:after remains disallowed we aren’t there yet?), CSS’ biggest saving grace is that it was a declarative and Turing incomplete.
Of course when the web first started, the idea was that it would serve stylablebut-unstyled-by-default content _and then the user would style it as they liked_ so they could enjoy a consistent and customized experience no matter what they were browsing. I don’t know many people that still customize their Browser default style sheets (can you even do that in Edge, I wonder?).
I personally don’t because I appreciate the value in judging people (and the content they produce) by how they’ve styled it (or haven’t, which can oftentimes be preferable).
EDIT
OK, with the caveat that I'm not a designer and have been told I haven't an artistic bone in my body, here's what NPR looks like with only some extremely basic CSS applied to html, body, and a elements and no changes to the actual HTML:† https://dev.neosmart.net/npr/1.html
And here's what it looks like with no changes to the HTML but with some additional CSS styling applied to the various sections of the document: https://dev.neosmart.net/npr/2.html
The focus isn't "design" per se, but merely readability. Less harsh contrast, fonts with better hinting, limiting horizontal eye travel, keeping content from reaching the very edges of the screen on mobile, and making the size of elements (and how much DOM real estate space they take up) match their relative importance.
† A charset=utf-8 meta tag was added to the HTML since the NPR document was served without a charset but contained UTF-8 encoded elements (instead of their HTML-encoded counterparts)
The vision of CSS included the notion of alternate stylesheets and some capability in browsers for the user to pick the stylesheet; as well as the notion of user styles which sometimes supplement, sometimes override the page author's style; all governed by the famous 'cascade' i.e. the resolution rules that determine which styles get applied [1][2].
Firefox (perhaps under its previous name, I can't remember) initially provided a statusbar-based UI to quickly switch styles, but it was removed [3] sometime in 2004. After that, browsers, if at all, only provided a bare minimum UI to switch stylesheets, usually though the application menu. Outside of hobbyist circles, page authors stopped providing alternate stylesheets. User-applied styles lived on in various ways: through addons, through alternate user-agents, but tends to be relegated to specific audiences or passionate fans of the capability; not a mainstream phenomenon.
EDIT: To experience this blast from the past, Mozilla has a sample page [4]. If the directions seem nonsensical, it's because the default browser UI now hides the menu bar [5], demonstrating just how obscure this option has become.
And in all honesty one of the easiest things to do in css is color themes, but marketing/designers tend to want to stick you to one “brand” or the css is implemented in a poor way to be able to swap colors. I’d love a dark theme for the New York Times but I doubt they’ll ever apply it.
Of course there’s all the edge cases with image based text which does pose a problem.. but I do wish designers would prioritize themes a lot more.
On the plus side, I think things like firefox reader mode are finally fulfilling this vision, just differently. Unlike custom css it's usable for average people too, it just needs more options like allowing web designers to turn it on by default, maybe some inline headers, etc. It's far from perfect but I consider it the first step in the right direction for 20 years.
My Firefox still has this... View > Page Style. It lists available stylesheets including none. Most websites are poorly designed and look like garbage with none.
Safari 11 still has this feature! Can you believe that?! I do indeed use a simple css file that sets a sans-serif font as the default (which I prefer). It's basically just this:
Oh I know. I'm lamenting the fact that default browser sheets suck (any sane developer/designer is going to import a CSS reset as the first step, so there's no reason to make the default look so ugly).
Of course, depending on the reasons behind the existence of thin.npr.org in the first place, NPR could add something really simple that doesn't add more than a few bytes and make it look several orders of magnitude more palatable.
You complain of 'ugly', but your 'beautified' version is harder to read, and I have normal vision and am using a big screen. It's a typical example of "designing for me", not "designing for everyone".
Screw the CSS, let the thin page stand as a thin page.
Because he's wanting the source to implement it server-side, for everyone. No-one would give a rat's arse if he was designing it for his own consumption and leaving the source alone.
I don’t know. All the objective literature I’ve read to date (sorry on a phone right now) has been to avoid harsh contrast, increase line spacing, avoid extreme contrast, and set a cap on max width. Just because you have a big screen (I wrote it on a 30” 4K monitor myself) doesn’t mean it’s wise to extend the content from Edge to Edge (not that this content is long enough to do that).
Some people need the whole size of the screen to be able to read. If you put a hard limit on the width, they will be very unhappy when they blow up the font-size to 200... But I doubt this works on any modern homepage anyway. Was a long time since I met these users last time. At that time there was still Netscape.
If you want to accommodate people with impaired vision who use large font size, define your content width in ems. I believe 90 characters per line is recommended but that's off the top of my head and I could be wrong.
Actually, the viewport meta tag is (being made) CSS [1], and it’s way beyond me why unstyled HTML is rendered unreadably small on mobile devices without it (and without any fixed layout to speak of)...
> it’s way beyond me why unstyled HTML is rendered unreadably small on mobile devices without it
Because browsers that did that would be both breaking spec compliance and introducing vendor-specific rendering, two things that IE proved were very very bad.
Every browser in use today has a default stylesheet that injects styles into every site (if not explicitly overriden). Even for sites that have their own stylesheets.
It's just that a) they're really ugly, and b) the mobile ones are ironically not mobile optimized.
They’re not necessarily overridden. Percentages and ems are units that are derived relative to their inherited style. If you make your browser default have a base font of 24px instead of 14px and someone back in 2010 made their site css defined as
html {
font-size: 2em;
}
Then your site’s 28px default font size that worked just fine on every browser now becomes 48px on mobile and breaks everything.
The problem arises without the viewport meta tag, and not on all browsers or devices. This site does use this tag, which has become sort of mandatory even when there’s no layout.
Yeah, there’s clearly little attention given to typography.
About a year ago I got tired of news websites pumping meaningless images and garbage to my browser so I put together https://legiblenews.com/ and focused mostly on typography with a system serif font (if you look at your request console you’ll notice I make one and only one request to load the page).
Kudos to NPR for doing this. I hope more news sites follow suite. I also wouldn’t mind server-side rendered text ads, if that ever happens.
In your second example, the total bytes in the page is 3697 bytes, the CSS makes up 948 bytes of that. You're spending about 25.6% of page weight on the CSS alone in that example. Your first example has a better ratio.
I'm not knocking you, as 3.7 kB is still incredibly light, and I think the point you were going for to begin with was to change the browser default stylesheet. Just wanted to post some stats.
Thanks. Yeah, I wasn't going for the byte-pinching approach (lots of good-old-fashion whitespace, not using css one-liner declarations, not bothering to refactor overlapping styles, etc); like you said, the intention was to simply show how a basic (user|site) stylesheet can result in a vastly more user-friendly result without going overboard.
(Now if you want to nitpick... I imagine the css has a better gzip/brotli compression ratio than the html by nature of its repetitive keywords.)
You’re right. We’ve become - by and large - engrained to associate links with underlines, but in this context it’s not necessarily necessary (though probably a welcome hint for many).
I'm really loving the html3/4 default typo. There are people advocating for "better" typography in raw text documents, but even if it's quite prettier, it's not the point.
In Safari, preferences > advanced, you can set a default stylesheet. I've put Bootstrap and the formatting looks nicer (though you loose the page padding). There should be a similar feature in all browsers.
Totally agree. It doesn't have to be a binary choice between 0 styles and JS and the full blown site. You can accomplish lots with a few hundred lines of CSS without really affecting load time noticeably.
You have to work very hard to bloat a non-JS, non-web-font page.
And all-inclusive build of CSS-only bootstrap (arguably the most fully featured CSS library there is) is <20kb compressed. That's the size of a several second animated GIF.
What animated GIFs are you talking about that are not several MB for a 5 second clip? It's 2017 and the only time my 2 gbps internet connection makes me think my browser has gotten stuck is when it's a gif (and not a recent mp4-masquerading-as-a-gif, I mean those uncompressed, "lets repeat all the content in the next frame even though nothing has changed" honest-to-god GIFs).
I wish there was a easy-to-find-downloads-of-audio NPR ...
But unfortunately, like almost all media outlets, finding an actual link that points to an actual mp3 file is very time consuming and difficult.
Here's an example ...
Let's say you want to download an episode of 1-A to listen to on an airplane. The front page of the website[1] has "listen" links and also a "subscribe to the "podcast"" link. But I don't want to "listen" and I don't want to subscribe to anything and I don't use itunes (or anything like itunes).
So you click the link to the actual episode of the show[2] but once again ... cute little "listen" link ... cute little "discuss" link ... but no way to download a file.
So now it's getting frustrating ... but as a last ditch effort, you turn off your brain and just type in "download 1-a episode" into google and come up with this link[3] which takes you to a different website (npr.org) which has a list of 1-a episodes (and our friend the "listen" button) but also has a cute little "..." button that expands into choices, one of which is "download".
You might find this NPR knowledge base article[1] interesting:
Every section of npr.org offers an RSS feed of its stories. To subscribe to a topic or show, paste the URL of a topic page, a program home page, or a story page into your RSS reader of choice. The reader should recognize the RSS feed within the page and allow you to subscribe.
Also, all podcasts from NPR and its member stations are available for RSS subscription. First, visit the NPR Podcast Directory and select a podcast. Then click the large blue “Subscribe” button and choose “Copy RSS Link” from the dropdown. Paste that link into the podcast application or RSS reader of your choice.
The NPR Podcast Directory[2] linked there seems like it may work for what you want. It shows all podcasts, and in each one the individual episodes all have that ... link you referred to. That looks to be the base site that you are finding through google, and it apparently has every podcast, so they have taken steps to make it easy to get them, there just seems to be poor discoverability for that project.
... which I have bookmarked and which largely solves my usability problem with npr(.org).
However, the general problem - which is that it's always a pain to find a static link to a regular file - persists. Not every publisher has a nice page like this. In fact, some of them have no way to get an actual file without subscribing or rss-reading or "listen now"-ing.
The simple test is this: is there a link that I can right-click, and copy, and feed to curl without any doctoring or scripting ?
My favorite workaround for this is starting the audio stream with chrome dev tools open and right clicking the network request and selecting "copy as curl". It's still more work but it's pretty bulletproof since the request it makes is identical to the one that comes from the browser.
I hate to say it but you might want to reconsider your stance on "anything like iTumes" there are really gread podcast specific clients out there that are lightweight, and to the point, you will also be able to download episodes for offline listening. I personally use Pocketcasts on Android. If you have an Android phone the Play Music app is already a podcast app on it's own.
Forgot to mention their web player. Definitely falls under not needing to download / install anything extravagant. Also shows how worthwhile Pocketcasts is in general.
I agree, there are solutions out there like the aforementioned that are easier than seeking out individual mp3s from the websites. Overcast on iOS and Pocketcasts I have both used and are good.
The Apple podcasts app is absolutely atrocious, and it only got worse in iOS11 where my podcasts aren't even in chronological order. (My previous gripe was that it simply refused to download podcasts until i hit cancel/download in succession for EVERY SINGLE PODCAST that was queued up, or else wait until some random time of day when it seemingly was able to download them all. This bug has persisted for years).
Unfortunately, I also play podcasts from my phone to my Sonos. It's bad enough that my bookmarks (last listened to location) aren't available when moving between the Podcasts app and the Sonos app, so the last thing I'm going to do is get a 3rd app into the mix where I have to manage subscriptions on 2 and listen on a 3rd.
Salman Rushdie's American Tale
2844294,https://downloads.wamu.org/mp3/1a/17/09/a2170925-2.mp3
35:13
Alabama Senate Race: More Than Moore-Strange
2844300,https://downloads.wamu.org/mp3/1a/17/09/a1170925.mp3
47:11
Manafort In The Middle
2807643,https://downloads.wamu.org/mp3/1a/17/09/a1170921.mp3
47:11
Actually, the you need to add dl=1 to the params to start a download and skip the webplayer on the links (at least in my browser), which is non-obvious until you compare to a download link on the page, not in RSS.
I think the assumption is that people who want to download shows are consuming them with a podcast client, which will download or stream as you prefer.
Why is this unfortunate? Podcasts are RSS feeds with direct MP3 download links embedded in them. It's hard to get more direct and standardized than that.
In the developer tools inspector, select the audio player and search for `div#external_player`, right click > "expand all", and there should be an "<audio>" tag. The `src` attribute of that contains the mp3 that you want.
I gave the steps so that someone can script it. Python and lxml takes 30 minutes to script something like this with no prior knowledge. It isn't particularly difficult, even if it is slightly time consuming.
Pretty sure the average computer user looking for NPR audio is going to be perfectly happy with the podcast - ie an RSS feed of the MP3 files with descriptions and show notes.
I think demanding the ‘raw mp3’ is a bit of a corner case here.
Stitcher lets you select episodes to "listen later" and can keep the latest episode of every podcast you subscribe to downloaded for offline listening as well. It's a good way to manage all the podcasts you want to have handy.
I don't get why Stitcher has so much market share. Stitcher injects audio ads, has terrible download bandwidth, and requires the app to hit their central server to download a podcast. I used sticher for the last three months and recently switched back to Downcast and never looked back.
After seeing the CNN one and now this, it makes me want to create a generalized service to turn any site into TXT format with the html2text [0] golang package.
Will submit to Show HN if I get enough round toits ;)
Here is the first pass; I still want to make it fancier so that links are clickable, but for a quick first stab I'm pleasantly surprised with the output quality:
In fairness NPR does in fact have RSS 2.0 feeds; they're separated by section [1] -- for example, one for US News [2]. There's an 'assorted' feed [3] that doesn't exactly mirror the homepage but shares a similar purpose.
The feeds only embed a line or two from the article, and link to the regular (i.e. non-lite) site. Nonetheless, they exist; artifacts of a patchwork of optimistic thinking about the future of the web that have largely fallen out of the collective popular consciousness.
If there are more text-only versions of sites, it seems like it may be cool to add a meta-view service in the style of HN or reddit. Is there an extant service that would easily allow this?
Ugh. I literally just spent several hours adding a workaround to fish shell that addresses a bug in Lynx that’s been around forever that randomly makes html content unreadable [0]. And that was only possible after a lot of research and digging!
How hard do you have to try to screw up the rendering of text only HTML?
It turns out that lynx applies styles (foreground color + optional background color + optional underline) to rendered documents (so you can tell where a link is, mainly) by calculating the hash of the (HTML element name, class) tuple of each DOM member (probably supporting just one class per element). It turns out that the insanely popular `<div class="contents"></div>` element has a hash that collides with that of `em.a` (a link in emphasized text) which styles the link to become readable in the default styling applied to `em`... but due to that collision, `<div class="contents"></div>` elements, not having the default <em> styling applied to them, become entirely unreadably (black on dark blue).
Lynx uses a very primitive hashing function (with a very small address space), and then (out of negligence or in the name of performance? Who knows!) doesn't check if the the (element, class) tuple (not its hash, but the actual tuple) matches that defined in the stylesheet...
To make matters worse, doxygen (arguably the most popular open source documentation generation software) generates the HTML versions of its output with all the content in a div assigned a class called.... yup, you guessed it, `contents`. And that's where fish and my workaround came in :)
Oh the nostalgia. The year was 1994 and I was a sophomore in high school. I downloaded Netscape via an FTP connection on my Macintosh LCIII. I opened it up and um, where do I go? What do I do?
All webpages were text like this at the time. I feel like it was efficient. You brought up a page and you read it. Now-a-days, for me, excessive graphics and bright colors distract from the content of the page.
I'd settle for an restricted subset of HTML only as a light standard. Tables and bold and h-tags and stuff are fine, it's CSS and Javascript that slow everything down for (on ordinary pages) basically no benefit. Reserve boxes for images but click/tap to fetch and show. Make always-show an option I guess. Videos are well-marked links that open in some other program. Let the user set some colors and sizes for basic text elements and call it a day. 99% of the web would be better for the user in such a restricted format and we could stop spending so much money peacocking up plain ol' websites.
If you remove HTML, you have more or less Gopher [1].
Maybe add back a subset of markdown to have a few semantic marks and ease navigation. Tables should be treated as what they are, that is formatted data that specialized software for viewing (it took way too long for HTML makers to realize that showing static tables that you can't sort or filter is only good at layout control).
You mean something like text/enriched? It was designed in the mid-90s to be something like HTML-lite for people who thought HTML (that is, HTML 2.0, not HTML5) was too feature-rich to be used for email. It also never took off.
It's not. Really. Lower contrast, crowded lines and skinny fonts aren't making things better. FOUC isn't making things better. The larger file(s) required to achieve worse results isn't making things better.
I really love these text-only minimalist news sites (http://lite.cnn.io, as another example). I read the thin NPR and lite CNN almost daily, and I'd love to see a list of these for other big news sites.
By far my favorite thing to do with them is customize them. I have a tiny plugin that styles the pages so that they are visually consistent, and I "fixed" the link issues in the articles so that when you click "Get the full experience", it takes you to the article's full version, instead of the home page of the regular site.
It is ugly and harsh on the eyes. There's nothing wrong with a minimal no-frills aesthetic, but that doesn't have to mean literally ripping _all_ styling out.
Hundreds of years of typography, typesetting... and what do some people claim to want? Naked html, default styling like a friggin' typewriter! Ugh!
I'll disagree with you. We should be putting our own styling on once it hits our computers. There's no reason that we couldn't design systems so that the client can style it to their preference.
>We should be putting our own styling on once it hits our computers.
99.999% of people don't want to design their own custom CSS for every website they visit, though. And the people who do could set custom stylesheets on any site they like. Nothing really needs to change in that regard, the best of both worlds is already here.
The default stylesheet can be a lot better - good enough for the aforementioned 99.999%. The defaults that we have at the moment date back to, what, late 90s?
But the vast majority of people view the complexity of modern design on the web as an extension of design in magazines - it's expected, and not a problem. Users would rather that work is done for them then have to do it themselves.
What you're suggesting might make a nice browser plugin, though. Stylish but with an integrated marketplace.
> majority of people view the complexity of modern design on the web as an extension of design in magazines...
Yes, because that's sort-of what it is!
There's a reason for styling. It makes things more legible, aesthetically pleasing and more fully expresses the intent of the content creator. We have different fonts and layouts for the same reason that buildings vary in design and materials. All buildings could be made of cinderblock and in the shape of rectangles but they're not, why do you think that is?
That's... exactly the argument I'm trying to make, here. Most people don't want the web to be as stripped down and minimalist as the site posted here, and asking them to style their own sites would go down about as well as asking them to bind their own books.
Exactly. I use this approach all the time on mobile with text-only NPR. I can browse fast over crummy or spotty service, and when I find one that I want to read in depth, I go to reader mode.
Unformatted text is much easier on my eyes than the grey crap that "designers" are so fond of these days. Its like they think everyone has an IPS screen or something...
Why not just have a more pleasing default style? Why does everyone who wants to send you information over the web have to worry about typography and typesetting, when you could just have something reasonable by default?
Readability is hurt by having body text in different font families, different weights, different sizes, different shades of gray on every other fucking website. Web designer can't choose readable font for me, because readable font is any one font I use the most.
The good thing is that Firefox still has option to override all fonts and use a single one chosen by the user. What is missing though is option to limit font weight to 400 and more.
At the moment I simply don't use websites that use thin fonts. Also websites that abuse fonts to display non-standard (non-unicode) icons fail utterly with user selected font families.
Other than that, having single font family everywhere is much more pleasant.
* Opens stories in expanded mode upon opening. No need to click
on the "Read more..." link each time.
* Clicking the "text-only" footer link from regular npr.org
attempts to go to the corresponding thin page, instead of the
thin.npr.org front page.
* Articles have smaller line-widths for easier reading.
It's interesting that I have to very consciously and deliberately tell my mind that this page is very new, the stories are very new. Somehow my mind just very strongly believes this is a legacy site.
Can someone explain to me why a news website needs HTTPS? Barring pages that require entry of financial information, why would you need to encrypt this kind of traffic? Is people snooping on what news articles you read a real concern?
But, yes, since ISPs may be getting into the business of analyzing and selling our browsing habits, https limits the amount of information that they see such as what particular page is viewed on a site. Certainly, that doesn't stop other ways to track, but it's a reasonable one.
No, the JavaScript has nothing to do with scrolling. Rather, it checks whether it's inside an iframe, and if so, navigates the top-level window to its own URL. In other words, it prevents you from embedding the site; if you try, your page will instead redirect to it. However, in the modern era, this kind of measure is neither necessary (because you can block iframing with CSP) nor effective (because the parent page can sandbox the iframe).
You know what, I really like this. Even with a site like drudgereport which is kind of text-like, it still feels like it's screaming at you. This is how news should be to allow me to form my own opinions in my head. The presentation might be slightly better with a google like description text underneath, could be that I'm used to that though.
I've always loved minimalist websites and text. Typography was my favorite style in my graphic design classes. Like Pixel Art I feel like these things can be implemented very well but get a bad rap for being "retro" or "dated".
Text-only doesn’t have to be _ugly_ though. Once you embrace minimalism, you realize that aesthetics are primarily a concept of white space and typography. And neither one of those interferes with text only, thank god.
While modern CSS has been inching towards becoming Turing complete (is it already now? I think so long as adding html elements via :before/:after remains disallowed we aren’t there yet?), CSS’ biggest saving grace is that it was a declarative and Turing incomplete.
Of course when the web first started, the idea was that it would serve stylable but-unstyled-by-default content _and then the user would style it as they liked_ so they could enjoy a consistent and customized experience no matter what they were browsing. I don’t know many people that still customize their Browser default style sheets (can you even do that in Edge, I wonder?).
I personally don’t because I appreciate the value in judging people (and the content they produce) by how they’ve styled it (or haven’t, which can oftentimes be preferable).
EDIT
OK, with the caveat that I'm not a designer and have been told I haven't an artistic bone in my body, here's what NPR looks like with only some extremely basic CSS applied to html, body, and a elements and no changes to the actual HTML:† https://dev.neosmart.net/npr/1.html
And here's what it looks like with no changes to the HTML but with some additional CSS styling applied to the various sections of the document: https://dev.neosmart.net/npr/2.html
The focus isn't "design" per se, but merely readability. Less harsh contrast, fonts with better hinting, limiting horizontal eye travel, keeping content from reaching the very edges of the screen on mobile, and making the size of elements (and how much DOM real estate space they take up) match their relative importance.
† A charset=utf-8 meta tag was added to the HTML since the NPR document was served without a charset but contained UTF-8 encoded elements (instead of their HTML-encoded counterparts)