Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The unreasonable effectiveness of simple HTML

shkspr.mobi

Post reply on HN
Print view View original

211–220 of 387 posts

Re: The unreasonable effectiveness of simple HTML

#211

Post by ndiddy »

chrismorgan wrote: post #95
salutonmundo wrote: post #63

The worst web browser I have access to is the "experimental" one on a Kindle 4. Most web pages that one might want to visit will not load in this web browser—because it does not support modern versions of TLS. For the reasons mentioned in this article—it's probably a good idea to keep plain HTTP access available on your websites.

The trouble is that you can’t support HTTP without completely undermining HTTPS. If you support HTTP at all , you’re damaging the experience for the almost everyone that could have used HTTPS: almost no one will get the HTTPS version unless you deliberately push them over to it, which you will only be able to do after page load by some JavaScript-based user-agent or feature-based sniffing, so now the page loads and t…

> almost no one will get the HTTPS version unless you deliberately push them over to it, which you will only be able to do after page load by some JavaScript-based user-agent or feature-based sniffing, so now the page loads and then reloads immediately, every time the user visits your site by URL

This is false. All you have to do is configure your webserver to only redirect port 80 requests to port 443 if the request includes the "Upgrade-Insecure-Requests" header. Obviously since headers are sent unencrypted this means attackers could easily bypass it, but it's still suitable for personal webpages with no user data. For example, here's how you do it in Apache:

RewriteEngine on

RewriteCond %{HTTP:Upgrade-Insecure-Requests} =1

RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]

Re: The unreasonable effectiveness of simple HTML

#212

Post by AtlasBarfed »

scooble wrote: post #184
lastofthemojito wrote: post #114

Earlier quoted context omitted.

One of the great things about accessibility is that it often doesn't just benefit people with disabilities. My wife and I have watched a lot of TV in the past year with the volume down and captioning on, while we enjoy some down time while our baby is sleeping. A ramped entrance to a building allows wheelchair-bound folks access, but it also helps able-bodied people using delivery dollies. Making simple, lightweight…

To add to this, a perspective I've heard working in the disability sphere is 'everybody is disabled eventually' - be that through injury, illness, or even just old age. This really challenges the view that thinking about disabled users is catering to the needs of a small group of the population. Whereas in fact it is bringing benefits to the majority of the population (at some point in their lives).

The culture of distraction distracts everyone from realizing they'll die.

Disability is just the fine print.

I remember walking around in a city after a parent died, and the world seemed like an illusion.

Re: The unreasonable effectiveness of simple HTML

#213

Post by lucasmullens »

labawi wrote: post #194
pvorb wrote: post #181

Earlier quoted context omitted.

I fully agree with all of your points. I just wanted to point out the irony that the manual and other documentation for this "inclusive design" toolkit come as PDFs – the worst choice you can make if you strive for accessibility.

I may be missing something obvious, but why is pdf such a bad choice? As long as it has actual text and is reasonably typeset (selecting text in this pdf seems to work properly), I don't see what's wrong. I'd take it any day over webpages with random floating content that you have to click through and use a modern browser with javascript without blockers/filters for the content to even render, in small text on 20% of…

I would assume PDFs don't typically work well with screen readers, which is what a large part of web accessibility is designed for.

Re: The unreasonable effectiveness of simple HTML

#214

Post by ratww »

SulfurHexaFluri wrote: post #192
michaelpb wrote: post #174

Earlier quoted context omitted.

A few years ago when teaching at a previous coding bootcamp that started with FE JavaScript, I remember my surprise when well-performing students got through 3 months or so of it and were confused and very impressed when I showed them how an tag worked, since they had only been aware of (jQuery) JavaScript powered pages. When you are stuck just doing JS powered SPAs, an tag seems like advanced technology! I ended up…

Almost every JS app I have seen uses a tags though. Even if they are just links to # pages. With most router libraries you can even use real paths and it works all on the front end. Sounds like you found one anecdotal case that didn't know this.

It definitely happens. I've seen some internship/junior interview tests where candidates use javascript's window.open or window.location to link to some fixed destination rather than just using an anchor tag.

Re: The unreasonable effectiveness of simple HTML

#215

Post by kstrauser »

Leherenn wrote: post #203
kstrauser wrote: post #58

Earlier quoted context omitted.

In the US, we collectively decided (via elected representatives) that this is important to us, and we passed the ADA to enforce it. Visually impaired people have as much right to use stuff as you and I do, and the law says so. From a purely economic point of view: if your competitor's website supports the visually impaired, and yours does not, then even though that's a relatively small market segment you're probably…

Do you have an example (outside of a niche, like a site catering specifically to some disability) of the economic argument working? Because the obvious economic counter argument is that while you work on accessibility your competitors work on features for the 90+% rest of the population. In my opinion it's why it's especially important to have regulations here, free market won't save us because in most cases the ROI…

Heh, not directly, but...

Once upon a time, a younger engineer worked for a company that dealt with the DOD. The DOD wanted to upgrade their website, and as often happens, the lowest bidder was a giant company who could blacken the sky with lawyers. They worked and worked, and their deadline slipped. Finally, they made something that kind of worked, sort of, as long as the wind wasn't blowing too hard.

The younger engineer noticed that the new DOD website served webpages via carrier pigeon, but with more latency. As in, page loads often took minutes. He proposed to the lord of his domain: "your majesty, what if I crafted a robot to visit all of their pages and enscribe their lore into our own tomes, such that when your customers want the information, we can give it to them in milliseconds, and not minutes. Oh, and I can make the robot labor only at night lest the DOD get persnickety." The lord gave his blessing, and the younger engineer went away and made The Thing.

The Thing worked wonders, and there was much rejoicing among the many kingdoms. But lo, the DOD was not happy, for it made their contractors look as though a pack of jackasses. And so they sent a sternly worded missive: "cease at once, knave, or we shall cut you off from the river of nectar for all of time!" And the younger engineer's lord's voice quavered, for he knew that his own kingdom would starve if this were to happen.

But the younger engineer was cleverer. He noticed that the DOD's website could not be perceived by those who could not see, but his own website was beautiful to behold by both the sighted and those not. He proposed a plan to his lord, and his lord giggled for the plan was good and clever.

The lord sent a missive of his own, both to the Maker Of The Website and the DOD, saying:

"Alas, your own website cannot be perceived by those without sight, as are some of our customers. Our website can be. If you go away and stop sending threatening letters, our customers have agreed to behold the riches of thine data through our site as a proxy, and not file a lawsuit with an injunction that shall turn your website off tomorrow until you spend a few tens of millions of dollars fixing it."

And the Maker Of The Website shut the hell up about it, and the DOD formally approved the plan, and all were happy.

Except for the Maker Of The Website, of course, but lo, they were as though a pack of jackasses.

The younger engineer was celebrated, then moved away to distant lands with better pay.

The end.

Re: The unreasonable effectiveness of simple HTML

#216

Post by ratww »

kaba0 wrote: post #208
ratww wrote: post #119

Earlier quoted context omitted.

My memories of non-web toolkits are not as fond as yours. You mention Swing, but I remember lots of my non-programmer friends dreading having to use applications made with Java, since they were considered sluggish and resource-intensive. They also had a certain look and feel to them that made them stick like a sore thumb compared to other apps, and a lot of people knew by looking when an app was made with Java. Java…

Back then, looking native was the most important thing. Today it seems electron apps can get away with looking anything but native - so perhaps it’s time to resurrect some other desktop frameworks (I just recently started working with JavaFX and I really like it so far. Unfortunate that it is so niche)

I think the issue with Swing was that is was in a bit of an uncanny valley. If all controls were custom it wouldn't look strange.

Visual Basic was very... well, "basic", so it looked normal. Some tools like CCleaner and a lot of Antiviruses had fully custom looks, but didn't look out of place, because they were too different.

JavaFX looks fine, though.

Re: The unreasonable effectiveness of simple HTML

#217

Post by ryandrake »

wffurr wrote: post #154
ryandrake wrote: post #147

Earlier quoted context omitted.

Admittedly most is just personal preference but the line width thing is the cardinal sin. Forcing huge blocks of whitespace on either side of the text for nebulous "readability" reasons is just wasteful. Too many web sites ape this pattern too. Look at John Gruber's website [1] on a nice wide 27" monitor for an extreme example. The content takes up less than 1/5 of the width of the screen. 1: https://daringfireball.n…

If only it was simple to configure my user agent to act as my agent and format things readably. I prefer moderate line widths. Even at half-screen on my 29" widescreen monitor, unformatted text is too wide.

Yes, this would be the best. Web site provides the content and the browser (user agent) decides how best to render it, potentially different than how the web developer would want it.

Re: The unreasonable effectiveness of simple HTML

#218

Post by Aeolun »

ahuth wrote: post #139
pbronez wrote: post #38

Earlier quoted context omitted.

Are there any automated ways to assess a web product against the Web Content Accessibility Guidelines (WCAG)? This should really be part of the CI/CD process.

Shameless plug: at work we created axe-storybook-testing [1], which can be used to run accessibility tests against Storybook stories [2] on CI. 1. https://github.com/chanzuckerberg/axe-storybook-testing 2. https://storybook.js.org/docs/react/get-started/whats-a-stor...

Oh, this sounds interesting. I’ll have a look.

Re: The unreasonable effectiveness of simple HTML

#219

Post by petepete »

anderspitman wrote: post #128
bachmeier wrote: post #53

Not really the point of the article, but I've been moving to plain HTML for a while now for certain types of personal documents. It's a great feeling to open a file in the browser and know it's going to work. Make a change and all you have to do is refresh the page. Markdown, org-mode, etc. have good intentions, and they work for super simple documents, but in the end the flexibility of html and its closing tags pays…

FWIW, I started going this direction and ended up taking one step back and settling on Markdown. The reason was I realized an HTML renderer is still a pretty heavy dependency to consume my content. The upshot is you can now browse my blog with curl or netcat: curl https://apitman.com/txt/feed nc apitman.com 2052 I may switch to another format in the future. It doesn't matter much as long as it's readable as plain tex…

I tend to write in Slim, it does an excellent job of removing most of the tag noise from HTML while giving you more flexibility than Markdown.

https://slim-lang.com

Re: The unreasonable effectiveness of simple HTML

#220

Post by eins1234 »

lastofthemojito wrote: post #114
ogre_codes wrote: post #10

This is a fantastic article, it does miss one very key point about bog-standard HTML which is worth mentioning though. The standard widgets are all accessible, people with screen readers, limited mobility, poor vision, etc, all rely on pages being written so the devices they use to read the web can function properly. People who choose to eschew these standard components very frequently end up with a site which is unu…

One of the great things about accessibility is that it often doesn't just benefit people with disabilities. My wife and I have watched a lot of TV in the past year with the volume down and captioning on, while we enjoy some down time while our baby is sleeping. A ramped entrance to a building allows wheelchair-bound folks access, but it also helps able-bodied people using delivery dollies. Making simple, lightweight…

Another great example of this is effective keyboard navigation is both an accessibility feature and something you can sell as a feature for power users who like to get things done as quickly and effortlessly as possible.
Post reply on HN