You Don't Need HTML | Hacker News Reader

You Don't Need HTML

shkspr.mobi

95 pointstomhazledine58 comments

This is fun and I understand it's a joke.

But since so many people do not understand the importance of HTML for accessibility, I feel the need to stress that this page may be a horrible experience for non-sighted people.

To sighted people, obscure unicode characters may look like text in a different font, but do they for screen readers? The same goes for ASCII art and the tables on this page.

Do all the fun stuff! But please draw the right conclusions for real-world projects.

I only clicked this story because I was worried someone was just using canvas and JS and ignoring the fact that it's entirely invisible to accessibility features. I heard there is ongoing work to introduce a direct accessibility tree API, but for now the DOM is required.

Instead it's much adieu about nothing since you could simply serve a text file.

That being said, <plaintext> is a nifty historical footnote I didn't know about, so that's cool.

Side note, a lot of people aren't aware that businesses in the US can be sued for violations of the Americans with Disabilities Act (ADA) for non-accessible websites.

much ado about nothing.

BTW, Shakespeare's Much Ado About Nothing was a pun on "noting" and entailed the passing of notes. I believe "nothing" was pronounced more like "noting" at the time.

and now without much ado I will say goodbye for this comment. Adieu.

Oh my sweet summer child! That may have been what your puritanical teachers taught you, but the truth is far more fun!

https://www.telegraph.co.uk/culture/books/booknews/8313901/T...

Shakespeare often punned about such "country matters".

Evil website. After about 10 seconds of reading, it gets replaced by a paywall.

They probably want to keep it alive, and provide you content as their day job.

Fair. Paywall up front then - don't tease me.

https://web.archive.org/web/20230426211700/https://www.teleg...

That's the whole, a single paragraph

oh whoops

Thanks for pointing this out. I'm visually impaired but don't tend to need a screen reader that often. But the times I do want/need to use one, I inevitably find things that are just awful. For fun, I tried turning on TalkBack on my phone and this demo site was completely inaccessible (TalkBack didn't pick up anything other than the archive.org controls). Maybe part of that is it being on archive.org, but I suspect it's due to the lack of any real HTML.

I'm curious how Talkback/Narrator handles this same content, but as a standard text file. I suspect it's still bad, but something about the weird HTML shenanigans being played might be messing up the screen readers.

Here's a direct link without the frame stuff if you want to try that:

https://web.archive.org/web/20230719135333if_/http://no-ht.m...

Do you have a way of uploading the page to gpt4? Perhaps it can annotate the contents for you by looking at the visuals.

> importance of HTML for accessibility

Can we simply say, Javascript driven SPA was a bad fad

I'm curious why? I built a JS-driven website and did extensive testing with the screen readers available to me (phone, etc). Adding a few aria properties seemed to work wonders. I think the problem isn't the SPA concept but rather that people don't bother testing. However, a horrible screen reader experience can be achieved without an SPA too and many do.

a well designed JS-driven website is OK, but I've seen too many "learn-react-in-30min" style unnessesary SPA that barely works and buggy bullshit.

To name a few:

- hard-coded buttons disguised as a hyperlink

- customized textbox/dropdown disallow copy-paste

- poorly defined broken URLs and important pages without a proper URL

the first two are just as easily replicated with MPA too.

JavaScript driven SPA is fine as long as everyone remembers that the entire and only point at the end of the day is to create HTML.

To be fair, the post which tells you “you don’t need html” is html. Which either is whimsical or a little odd.

I can see ascii art being a nightmare for screen readers.

It's also extremely laggy on my phone browser. Go figure.

RFCs were originally formatted as plain-text, and render well on most browsers (as long as the viewport width can fit 70 characters).

The first time I inspected one in a modern browser devtools, I was confused: "where's the HTML? How do they do this layout?". It's done with spaces, same way as you would with a typewriter.

https://www.rfc-editor.org/rfc/rfc2324.txt

You can totally add some invisible tags for semantics.

What I love about these documents is how beautiful, clean and readable they are. How do do it myself, I don't know, but would love to

They don't render well even outside of the huge smartphone use case because they lack trivial formatting present even in the old printed medium (and even typewriters were richer, could retype the same char on the same spot to make it stand out or use underlines)

I’m puzzled by the first line, the HTML framing. Why not just serve it `content-type: text/plain; charset=utf-8`?

A byte-order mark (BOM) would have the highest priority. [1]

BOM > HTTP charset > HTML meta charset

Also works for local files (not served over HTTP).

> You could skip the meta encoding declaration if you have a BOM, but we recommend that you keep it, since it helps people looking at the source code to ascertain what the encoding of the page is. [1]

[1] https://www.w3.org/International/questions/qa-html-encoding-...

If you send Content-Length: text/plain, I believe there's no browser that will render it as HTML anyway.

This reminds me of the old GameFAQs before everything was monetized blogspam. You knew you had a good guide if it had a decent ASCII art header.

Responsive... "In that it generates a violent response from web designers. "

Didn't know about plaintext.l element. Could have just set content-type: text/plain; charset=utf8 though. Then it really would be no html

You absolutely can make a website without any HTML, not even a scrap of invalid markup.

Just use SVG. It does not need to be embedded in HTML to work.

Why stop there? Use arbitrary XML and style it with CSS.

> <meta charset="UTF-8"> is real. Without this, text encoding sniffing takes places and some browsers just displayed rubbish.

I am curious. Which browsers do this? I thought this tag is unnecessary in HTML5 because the information that the page is UTF-8 encoded is already implicitly conveyed by the DOCTYPE. (UTF-8 is the only encoding allowed for HTML5.)

As you can see, I didn't use that doctype. I experimented with a few older browsers (and one of those online virtual testers) and a few displayed weird results without it.

Ok, thanks for the clarification! I took "Without this, text encoding sniffing takes place" to mean that this happens in general.

I tried rehosting this file on localhost and removing the <meta charset="UTF-8">, breaks it in the latest versions of Safari, Firefox and Chrome

I tried to fix it by replacing the fake doctype with <!DOCTYPE html>, and it fails in the same way (but the page gets slightly more padding in the top of each page, proving it's doing something to switch modes).

Can also try saving the file with a UTF-8 BOM. [1]

BOM > HTTP charset > HTML meta charset

[1] https://www.w3.org/International/questions/qa-html-encoding-...

I cannot reproduce this. I used VSCode's live previewer to host the file on localhost (macOS) and tried with the browsers you listed. Removing the meta tag or changing the doctype did not make a difference.

Is it possible that you accidentally deleted the `<plaintext>` tag when making your changes? That breaks the page for me.

I live in Japan, try changing your OS language from English to Japanese - in Japanese a lot of things switch to defaulting to Shift-JIS instead of UTF-8 when nothing is specified.

Didn't need to. When hosting per `python -m http.server 9000` I get the same result as you. Very interesting. Thank you for bringing this to my attention.

Funny, but I’m saying it seriously as a countermeasure to the bloat epidemic. An SMS parking app doesn’t even need Internet and works fine. Use the simplest technology to achieve a goal and enhance.

You forget the fact that bloat is driven by many stakeholders, not just developers. Bloat is the consequence of ever increasing demand for bells and whistles, the pressure to release something (case in point: github projects that don't get updates every other month are considered dead) amongst other factors.

An SMS parking app works fine as long as you limit it to the very specific use case. As soon as the "enhance"-part enters the picture, chances are simplicity leaves the scene at the same moment. Complexity can only be avoided by keeping the problem simple.

As someone who travels a lot, SMS based app stuff is one of the most annoying common problems.

It’s easy to find a way to get internet anywhere, but getting an sms message at a phone number is way harder (or easy but expensive); bonus points if you restrict it to local phone numbers only. Lots of countries require ID checks to get a local number and the system breaks with foreign IDs.

Add less, ship less, worry about less. -- HTML is all you need to make a website

But if I could, I'd like to add none, ship none, worry about none. My employer made me add so many shit. I have no choice.

It would be fun to have something like Advent of code, but for arbitrary restrictions.

The grand finale could be making something without using a computer at all or buying anything (Not even for research, you have to use actual books or talk to people), and trying to use as little tech as possible.

Like, you can use a power drill, but if you use a brace and bit you get extra points. You can document with a phone camera but if you can draw you might want to illustrate instead.

I particularly like the Arecibo message part. Shame the OG site doesn't seem to be up, but glad there's a waybackmachine link in the post

Sadly the domain name was from Freenom. All of the names registered with them have gone. I can't find a way to get my Mali domains back.

Oof. That's a shame. I've seen some folks automatically switching out dead links on their blog with archive.org versions. Is that something you're doing, or did you manually switch the ones you knew were gone?

I have a WordPress plugin which scans for broken links and then offers to replace them with archive links.

But those I did manually.

I was expecting this to be all JS drawing to a canvas (which, I know, is technically HTML) but this is pretty good too.

Thanks for the tip about <plaintext>. I think it will be very useful in some cases.

It's been years since I saw it, but there was someone who was convinced pdf should have become the standard for web pages and did a site in pdf only.

Assuming I remember correctly.

We all need more EBCDIC in our lives. The flow chart is lying.

"We're way out of our league here.

After all, we're up against the brightest minds in the world, the scientists who invented the world wide web."

And besides, what about links?

    You do it like this [0]

    [0] https://...

But I can't navigate to that - neither by clicking, nor by keyboard navigation.

Copy and paste.

UA issue then. Maybe use Vim and some extensions?

https://yourworldoftext.com has a similar aesthetic, although JS-based

Reply on news.ycombinator.com