Live data from Hacker News

The unreasonable effectiveness of simple HTML

shkspr.mobi

181–190 of 387 posts

Re: The unreasonable effectiveness of simple HTML

#181
post #141

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…

> One of the great things about accessibility is that it often doesn't just benefit people with disabilities. I really love how Microsoft's design team has pushed this with their “Inclusive Design” concept[1] and highlighting how any sort of disability can be situational (holding a baby), temporary (broken arm), or permanent (missing arm) but we often only think of those in the last context despite there being orders…

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.

Re: The unreasonable effectiveness of simple HTML

#182

Earlier quoted context omitted.

While I agree with your message of "make things accessible" I think you're pointing the finger the wrong way. > 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 functi…

FWIW, using React or whatever makes it more obvious that you're making these mistakes because your event handlers are attached right on the "HTML" element. It makes it easy to spot because you see and it immedaitely sticks out as a mistake. Because its easier to statically understand these mistakes, theres even tooling to automate detecting some of them as you type https://www.npmjs.com/package/eslint-plugin-jsx-a11y

> FWIW, using React or whatever makes it more obvious that you're making these mistakes because your event handlers are attached right on the "HTML" element. It makes it easy to spot because you see

>

> and it immedaitely sticks out as a mistake. Because its easier to statically understand these mistakes, theres even tooling to automate detecting some of them as you type https://www.npmjs.com/package/eslint-plugin-jsx-a11y

I'm not sure how you got that out of

> I have seen an increase in unknowingly doing so by importing a calendar widget or similar without reviewing it.

I'm referring to:

    
VS:

    
The point of using components is so that you don't have to look under the covers to understand them at a high level, but that also means if you don't look you don't see how they're breaking accessibility.

Re: The unreasonable effectiveness of simple HTML

#183
post #100

Earlier quoted context omitted.

> Very few people have the skill to turn a div into an effective button, yet over and over I see web sites with rows of buttons which are in fact just divs with javascript behind them. What was the catalyst behind this trend? I just don’t understand the reason behind it. Hasn’t been around forever? Was there some limitation on the button tag that made the div tag more desirable?

You’ll find it’s because until “recently” (depending on how long you’ve been in this game, cough some of us since before css was even a thing) buttons weren’t stylable like they are now. There’s no good reason to just not use buttons these days, but for a long time that wasn’t the case (cross platform).

is also substantially older than both and . The only button like thing before HTML4 was .

And, as you mention, the default styling was typically "make it look like the button in the underlying OS".

So there was a lot of inertia from existing code, examples, and docs that predated buttons. And a (misinformed) avoidence of it when it did appear because of styling.

Re: The unreasonable effectiveness of simple HTML

#184

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…

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).

Re: The unreasonable effectiveness of simple HTML

#186

The simple HTML of Hacker News is one of the reasons I love it so much. What a breath of fresh hair compared to modern Reddit.

Yeah. tags for presentation (with no `alt` attr). Form s without s. No skip link, no landmark regions. s with s inside for non-tabular content. tags. FONT TAGS. "A breath of fresh hair" is a typo that accidentally makes a good comparison.

HN gets only 1 bag of popcorn

Re: The unreasonable effectiveness of simple HTML

#187
post #96

Earlier quoted context omitted.

I would argue that the fact that video content is often so frustrating to scrape is symptomatic of the massive cultural shift the web has seen over the past decade or two. In the "old" web you could basically right-click -> save anything you want (ignoring plugin blobs for the sake of making my point more compelling). Meanwhile I tried manually scrapping a video from reddit the other day, I succeeded but it was quite…

Firefox exposes this stuff just fine: its context menu on videos has “View Video”, “Copy Video Location” and “Save Video As…”. (I thought that Chrome did too, but maybe my memory is faulty or maybe they removed it at some point.) But sites can easily prevent all of this stuff from happening by putting something transparent on top of the video, so that you’re not actually right clicking on the video, but on another el…

> Firefox exposes this stuff just fine: its context menu on videos has “View Video”, “Copy Video Location” and “Save Video As…”. (I thought that Chrome did too, but maybe my memory is faulty or maybe they removed it at some point.)

You're right, I never noticed that. Although I just tried on youtube and the option are there... but greyed out. Not sure why.

As for the various formats, if the web wasn't a javascript shitfest that would be exposed to the browser and it would decide what format it wants to use. That would help with all these websites with a crappy streaming implementation. That would also make downloading very easy, you could just select which format and bitrate you want.

Re: The unreasonable effectiveness of simple HTML

#188
post #179

Earlier quoted context omitted.

> Embedded javascript to make them responsive. We must have different definitions of 'responsive'. You don't need javascript to make a website look different due to different screen sizes.

They might have meant actual responsiveness, as in the absence of lag. On low-end embedded devices, rendering a template with something like PHP could easily take high units or even tens of seconds, whereas JS on a much more capable client device can respond to the user's input immediately.

Right. Populating pulldowns, updating dynamic lists (available APs after a scan) etc.

Re: The unreasonable effectiveness of simple HTML

#189
Made me think of a time I didnt do adequate research before buying an expensive flight ticket: I was in Changi Airport and had a cheap return ticket to Malaysia, when I got back I was going to travel in the east coast of Australia for a few weeks as the end of my study abroad in Asia. It dawned to me that I never actually checked the Visa rules for Australia, but just pressumed that they would be like any othet commonweath country I had previously visited. Turned out I was lucky and didnt need a paper visa, but could do with an e-visa. As my HTC Desire Android phone had died in the humiddity, I only had the cheapest nokia I could find, X-1 ... Armed with a 2011 public internet kiosk of internet explorer, I tabulated through the australian immigration forms and found the correct form, filled it out while my browsing session of the kiosk expired, after a few tries, I knew exactly the way around the static site, and was what some would call "speedrunning" through their website. After sumbitting I just had to hope for the best. If that site had been required any more than it did, I am not sure I would have been able to submit my application through that public internet browser.

Re: The unreasonable effectiveness of simple HTML

#190
post #36

Earlier quoted context omitted.

I didn't make myself clear. The embedded device is the web server in this setup. The browsing device (phone, tablet etc) runs javascript. You're right, no way a tiny embedded device runs javascript.

Javascript is available for microcontrollers within various ram footprints. Here's one mentioned recently on HN https://jerryscript.net/ There's even benchmarks for them. https://bellard.org/quickjs/bench.html

Cool!
Post reply on HN