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

261–270 of 387 posts

Re: The unreasonable effectiveness of simple HTML

#261

Post by inopinatus »

elliekelly wrote: post #18
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…

> 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?

Ironically, it's because of the ARIA Authoring Practices guidelines[1], which include exactly this sort of nonsense[2].

[1] https://www.w3.org/TR/wai-aria-practices/

[2] https://www.w3.org/TR/wai-aria-practices/#examples

Re: The unreasonable effectiveness of simple HTML

#262

Post by Stevie300 »

pvorb wrote: post #181
acdha wrote: post #141

Earlier quoted context omitted.

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

What sort of file types are preferable? I'm not very familiar with accessible tech.

Re: The unreasonable effectiveness of simple HTML

#263

Post by giantrobot »

fouric wrote: post #90
theandrewbailey wrote: post #71

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.

What if you do, though? Flexbox is a CSS 3 feature. Support appears to have been implemented in FF and Chrome around 2012-2014 and still doesn't fully work in IE[1]. The fact that a site uses CSS and HTML instead of Javascript does not imply that it's easier for older browsers to display. Javascript 1.0 was released in 1996. [1] https://caniuse.com/flexbox

Flexbox is by no means necessary to make a responsive web page. Media queries have been supported by mobile browsers for over a decade as has the viewport meta tag. Between the two it should be straightforward to make most page designs responsive.

Old browsers (old IE especially) that don't handle those features aren't a problem because they'll just fall through to the screen style. Trying to use JavaScript to help old browsers is a worse solution as you're more likely to run into JavaScript incompatibility problems than CSS.

Re: The unreasonable effectiveness of simple HTML

#264

Post by michaelpb »

scrollaway wrote: post #258
michaelpb wrote: post #180

Earlier quoted context omitted.

This is just a personal preference. I would say the same about Python / Django: You get extensible login/signup/password-reset/etc authentication & user-permissions management, and even an admin interface with user groups, right out of the box. I can put together a web app in "60 seconds" that would take weeks to assemble using the JavaScript ecosystem. Having taught classes on both, I'd also say it's also easier for…

Django's user system is .. limited. You need a bunch of third party libraries to add very commonly used things such as auth APIs, oauth, 2fa, etc. I've worked with Django for over a decade and i dislike it more and more. It hasn't evolved to match the environment around it and how to best use it. Typing is missing. Something like FastAPI is very promising but Django's admin is still superb for prototyping and its orm…

Agreed, it definitely is limited. Also the admin panel is limited too, and although it's very extendable, the admin extension API is kind of clunky and inconsistent at times. Yeah FastAPI looks great! I've used Sanic in the past and FastAPI seems cool for some of the same reasons. I'm also following closely Django Hotwire - https://hotwire.dev/

I only brought up Django in a narrow context to challenge an assumption made by the post I was replying to, that seemed to imply that JavaScript ecosystem is indisputably the fastest for rapid prototyping. Hence my providing of a counter-example. I think this is especially true for new coders, as having certain things out of the way is super vital to keep motivated when building MVPs -- I've seen many students give up on ideas simply because implementing authentication with a Node.js-based stack was too challenging, when they would have been happily coding away had we been teaching a batteries-included framework (django / rails / etc).

Re: The unreasonable effectiveness of simple HTML

#265

Post by viraptor »

lucasmullens wrote: post #213
labawi wrote: post #194

Earlier quoted context omitted.

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.

As long as they're produced in a reasonable way, they work just fine. The option was even included natively in adobe reader 9 https://www.montgomeryschoolsmd.org/departments/hiat/tech_qu...

Where it breaks down is some badly designed OCR systems which place the letters independently rather than in lines/blocks. But that's starting from a document which was not accessible in the first place, so not a huge issue.

Re: The unreasonable effectiveness of simple HTML

#266

Post by kortilla »

K0nserv wrote: post #99
kortilla wrote: post #97

Earlier quoted context omitted.

If the site looks correct visually, the designer has actually completed their job. You’ll find that very few businesses care how a page is implemented and happily pay for shit html if it looks right.

That might be the way many companies work, doesn’t mean it’s correct. Design is more than how things look, in fact how things look is secondary.

But that’s what a designer’s “job” is when they work for a company.

Re: The unreasonable effectiveness of simple HTML

#267

Post by forgotmypw17 »

tommica wrote: post #175
forgotmypw17 wrote: post #168

Earlier quoted context omitted.

Not every website requires passwords or any other secrets to be transmitted. I use a combination of fingerprinting and WoT to allow (but not require) anyone to maintain an identity without having to register or sign in.

What is WoT? Does your system send a single-use code to the email, or some other method? I cant imagine a way to login to the account without some secret key, and that creates a dependency that might make the app unusable in another way on older devices.

I use a combination of cookies, fingerprinting, and web-of-trust verification (by volunteer moderators). The WoT works by building a DAG of "vouch" tags for each user. For more capable browser, client-side signing using a private key is available.

There is always an accessibility-security gradient, and there are trade-offs you have to make on every side. The needs of each user are different, and many would prefer to trade a lot of security for a lot of accessibility.

For example, if someone un-housed is only using borrowed devices, older tech, library computers, public wifi, many would happily trade some security for being able to let their loved ones know they're OK.

They're not worried about espionage or privacy, they just want to be able to send an "I'm OK" message to their family every day or two.

For this type of scenario, and many others like it, a simple http-accessible website behind a simple password is by far the best solution I've found to date.

Re: The unreasonable effectiveness of simple HTML

#268

Post by euske »

> 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?

This is such a quotable paragraph. It also reminds me of this:

"Do what you can, with what you have, where you are." - Theodore Roosevelt

Re: The unreasonable effectiveness of simple HTML

#269

Post by ori_b »

Aeolun wrote: post #198
reificator wrote: post #182

Earlier quoted context omitted.

> 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-js…

Depends on how far you are linting it? If you lint your node_packages folder you may still catch these.

When was the last time you removed a dependency due to lint errors? How about your coworkers?

Re: The unreasonable effectiveness of simple HTML

#270

Post by stjohnswarts »

This article has a lot of good points. I went to my county's covid page to sign up for the vaccine wait list. It could have been one page of about 10 questions and radio button (and other basic controls) and a submit button. But nope, it had 500k of god knows what javascript being downloaded for transitions and fancy buttons and 5 pages of really nice looking questions. All I wanted to do was register for a wait list! Imagine older people (who I'm all have surely filled out simple online forms) with older computers going through this stuff. Or someone who is blind. It's ridiculous.
Post reply on HN