The unreasonable effectiveness of simple HTML • Hacker News Board

Re: The unreasonable effectiveness of simple HTML

#31

Post by ogre_codes » Wed, Jan 27, 2021, 6:27 PM UTC

rstupek wrote: post #23

arcturus17 wrote: post #15

Earlier quoted context omitted.

> Making your site accessible isn't just a good practice, in the US, it is the law > Courts have rules that the ADA applies to web sites along with any other type of business For a business like a coffee shop I'd imagine that accessibility is codified in law through things like building regulations (ie, you must have n disabled parking spots per square foot, a disabled toilet, etc) Is there an equivalent legally codi…

There is not a codified standard however that doesn't stop websites from being sued

If you comply with the WCAG 2.1, you have a pretty good legal defense. While it isn't "Law", it is the most widely known published standard and likely to be added to the law soon.

https://www.w3.org/TR/WCAG21/

Re: The unreasonable effectiveness of simple HTML

#32

Post by [deleted] » Wed, Jan 27, 2021, 6:27 PM UTC

arcturus17 wrote: post #15

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…

> Making your site accessible isn't just a good practice, in the US, it is the law > Courts have rules that the ADA applies to web sites along with any other type of business For a business like a coffee shop I'd imagine that accessibility is codified in law through things like building regulations (ie, you must have n disabled parking spots per square foot, a disabled toilet, etc) Is there an equivalent legally codi…

[deleted]

Re: The unreasonable effectiveness of simple HTML

#33

Post by mschaef » Wed, Jan 27, 2021, 6:28 PM UTC

zelphirkalt wrote: post #7

antihero wrote: post #4

Different solutions for different problems. You have a different design requirement when you are designing something for use by the most vulnerable and those without access to reasonable technology. This absolutely needs to be factored in when choosing how to build something, however, this is a tiny subset of users, and this is for essential life-is-in-the-balance types of service. The vast majority of users will hav…

I think this is an exclusionary mindset. Just because it is a tiny subset of users, it is OK to exclude them? How about when it is quite easy in many cases to support them, by using standard conform simple HTML? Example: How many login forms have I seen, which will not show their input fields, if I do not allow their shitty scripts to run? In fact, just today I have seen it, on a VPN login, on a thing, that is suppos…

> Example: How many login forms have I seen, which will not show their input fields, if I do not allow their shitty scripts to run? ... They don't know the noscript tag or something?

This is often less about the developers not knowing a technique and more about the constraints they're working under. Maybe there's a third party auth library they're using that requires JS. Maybe either they or or their management have other priorities than removing JS from the login screen. It's not that hard to believe that scriptless login would fall fairly low on a team's priority list behind features more likely to drive revenue, etc.

Re: The unreasonable effectiveness of simple HTML

#34

Post by thehappypm » Wed, Jan 27, 2021, 6:28 PM UTC

Ads need JavaScript, in general.

Rich logging/event tracking needs JavaScript, in general.

Native Apps tend not to be HTML-powered, they're powered by APIs that can also power Web sites that use JavaScript, again, in general.

A lot of these corporate-ey features rely on JS.

Re: The unreasonable effectiveness of simple HTML

#35

Post by john37386 » Wed, Jan 27, 2021, 6:29 PM UTC

Excellent story. It's true that sometimes we should go back to the origin of the web, when it was mostly grey. I miss that web. I feel that it was an art to make it that ugly, but for me it was beautiful to the eyes.

Re: The unreasonable effectiveness of simple HTML

#36

Post by kwdc » Wed, Jan 27, 2021, 6:29 PM UTC

JoeAltmaier wrote: post #5

mattl wrote: post #3

Earlier quoted context omitted.

And what if the device can't or won't run JavaScript?

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

Re: The unreasonable effectiveness of simple HTML

#37

Post by red_hare » Wed, Jan 27, 2021, 6:31 PM UTC

pbronez wrote: post #20

Love this: > Go sit in an uncomfortable chair, in an uncomfortable location, and stare at an uncomfortably small screen with an uncomfortably outdated web browser. How easy is it to use the websites you’ve created? It's so easy to get disconnected from the real-world applications of our technology. Build user empathy.

My favorite example of this was when I worked on a B2B product with a daily email report. We noticed the most common usage of this email report came from native iOS email clients first thing in the morning.

As a test, my team all went home and practiced being the user. We had a test email sent to our email addresses we would open first thing in the morning and attempt to make sense of it while laying in bed.

The result was a lot less cruft, bigger text, and key takeaways above the fold.

Re: The unreasonable effectiveness of simple HTML

#38

Post by pbronez » Wed, Jan 27, 2021, 6:31 PM UTC

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…

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.

Re: The unreasonable effectiveness of simple HTML

#39

Post by kwdc » Wed, Jan 27, 2021, 6:32 PM UTC

glitchc wrote: post #16

antihero wrote: post #4

Different solutions for different problems. You have a different design requirement when you are designing something for use by the most vulnerable and those without access to reasonable technology. This absolutely needs to be factored in when choosing how to build something, however, this is a tiny subset of users, and this is for essential life-is-in-the-balance types of service. The vast majority of users will hav…

I hear you: Businesses have no incentive to cater to niche segments of the population as they are not revenue drivers. What you call "enhanced experience," I translate to "adverts" (what else?). How can government compel businesses to provide better experiences? Why, standards and regulations of course.

A massive fine might help.

Social pressure in the form of "corporation xyz only supports ie6 for their bank website" is another way.

Re: The unreasonable effectiveness of simple HTML

#40

Post by iforgotpassword » Wed, Jan 27, 2021, 6:36 PM UTC

simias wrote: post #12

JoeAltmaier wrote: post #2

Client-side javascript is underrated. We put simple websites in embedded devices with shockingly low memory/flash. They're for configuring the device. The pages are pretty serviceable with html controls, color schemes, logo etc. Embedded javascript to make them responsive. A couple of kilobytes total html.

I concur. I wrote a web interface for a crappy 20yo DSP last year, the thing doesn't even have an MMU and only 32MB of RAM. I basically put all the code in the browser, on the device there's only a very simple C HTTP server that serves the static files and blobs of data. In the end the UI looks fairly modern and responsive even though the backend is potato hardware. I wouldn't say that client-side JS is underrated th…

For YouTube I kind of still see a point, if only to not make scraping videos dead simple by not just having the plain URL of the video file in the html (yes there are still tools out there).

But twitter is so ducking ridiculous in that regard. At its core it is a web site to share 280 character long strings, but as of recently you cannot do this anymore without JavaScript! They shut down the legacy page at the end of 2020 that was blazing fast and a pleasure to use. And what irritates me the most about their modern Js based mobile page is that it frequently happens that I tap a twitter link on HN which takes forever to load, then it shows two blue spinners one at the top and one in the center and then after another eternity it says "this content isn't available". Then I hit reload, the whole thing repeats and this time the 280 characters display just fine. How? Just how do you end up with this?