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

231–240 of 387 posts

Re: The unreasonable effectiveness of simple HTML

#231

Post by TeMPOraL »

ryandrake wrote: post #217
wffurr wrote: post #154

Earlier quoted context omitted.

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.

And that was the original goal. Sadly, the marketing people won and turned the web into a glorified magazine delivery service.

Remember when browsers supported user styles out of the box and put them in a somewhat discoverable location?

Re: The unreasonable effectiveness of simple HTML

#232

Post by ogre_codes »

tyingq wrote: post #183
aidos wrote: post #100

Earlier quoted context omitted.

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.

The button html element is old enough to vote.

Since it's introduction, jQuery was born and died. Backbone was created and became obsolete. React took over the internet. Webpack, babel, and node were invented.

With all that change, I think it's safe to say web technologies are adopted or not based on inertia.

I think you are being over-generous.

Re: The unreasonable effectiveness of simple HTML

#233

Post by TeMPOraL »

turtlebits wrote: post #136

Part of the problem is that once you expand past a single read-only document, things like navigation, routing, user input/forms- get complicated. Devs want friendly URLs, static sites for easy deploys (ie no backend for form processing).

That's true, but vast majority of websites are just a collection of interlinked single read-only documents. There are various reasons why they get overloaded with JavaScript, and none of them are beneficial to the reader.

Re: The unreasonable effectiveness of simple HTML

#234

Post by perl4ever »

iso1631 wrote: post #42
another-dave wrote: post #11

Earlier quoted context omitted.

I don't think the problem is that niche though. Even outside of accessibility concerns, there are plenty of times I've tried to use websites on smartphones within intermittent internet access — e.g. on the London underground checking in to a flight on the way to the airport or ordering a pizza when coming home late from work. In both scenarios, I'm trying to complete my task as quickly as possible while I still have…

> so many things are designed and tested by people on T1 broadband in a downtown office I wish. A T1 is 1.5mbit. CNN's front page is 6MB - 30 seconds at full T1 bandwidth.

I can't remember exactly how much it was, but within the last year, I ran out of cellular data and my "unlimited" plan dropped back to a lesser amount of bandwidth, but still what used to be broadband. However, I literally could not load any website I tried. However much it was, it was way more than dialup. It seemed to me like there was no point in a soft cap, if one can't even load the website to change plans.

Re: The unreasonable effectiveness of simple HTML

#235

Post by Wowfunhappy »

dvdkon wrote: post #227
Wowfunhappy wrote: post #207

Earlier quoted context omitted.

My question is why so many users keep their browsers maximized! I bought a wider monitor so I could comfortably have multiple windows open at once. And by "wider" I mean from 1024x768 to 1080p, and by "bought" I mean "bought a decade ago".

Because once one site starts needing X px, most users will just keep their browser at least X px wide. At some point X became so close to the monitor's resolution that not maximising the window is just extra work. I'm not happy about having to maximise my browser, but I would be less happy about having to scroll horizontally. There are definitely some people who just maximise everything out of habit, but I don't thin…

No, I actually don't think websites have much of a problem with this. I generally keep my browser around 1,000 pixels wide (more or less depending on what I"m doing), and websites generally work fine. Responsive design helps a lot, as you say.

What surprises me is how many users seem to keep their browsers maximized at all times, particularly on desktop-sized displays! I'm pretty sure I see people doing it more on Windows than on Mac for some reason, which makes me wonder if it's a UI design problem (of the OS, not websites).

Re: The unreasonable effectiveness of simple HTML

#236

Post by tyingq »

ogre_codes wrote: post #232
tyingq wrote: post #183

Earlier quoted context omitted.

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.

The button html element is old enough to vote. Since it's introduction, jQuery was born and died. Backbone was created and became obsolete. React took over the internet. Webpack, babel, and node were invented. With all that change, I think it's safe to say web technologies are adopted or not based on inertia. I think you are being over-generous.

Perhaps. I happen to be in a space with lots of "old enough to vote" code still running.

On the other hand, the Compose "button" in gmail is ... a :

Compose

Re: The unreasonable effectiveness of simple HTML

#237

Post by aflag »

SulfurHexaFluri wrote: post #191
ratww wrote: post #68

Earlier quoted context omitted.

As someone involved in hiring, this is what Bootcamps and Universities are teaching, and what companies are looking for: backend spits JSON, frontend consumes it using React. Rendering HTML on the server is not really "the default" anymore as it was 10 year ago: it's more of an optimization for when your React site is slow, and it's a black box to most people. Even static websites are "strange tech" to new graduates…

>The issue is that a lot of developers will want to use React for everything else on the page, because they think it's "icky" to use other kinds of tech in other parts of the website. It is though. I work on an app thats 80% react and 20% rails SSR and when working on anything, seeing that an area that needs change is written with SSR makes the job 10x harder as you have to come up with alternative methods to get it…

It feels more like the SSR part was not the right tool for the job in this case (or maybe it was from the speed point of view and not development). Your point seems to be that react is better than SSR and not that mixing technologies is bad.

Re: The unreasonable effectiveness of simple HTML

#238

Post by colejohnson66 »

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 PDF is essentially saying, “put this thing here”, you’d think it wouldn’t. But it does. You can embed the source text for screen readers. It’s also how copying text from PDFs works.

Re: The unreasonable effectiveness of simple HTML

#239

Post by scrollaway »

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.

PDFs can be accessible, and many of them are! Everyone who works with PDF needs to know about PDF/A:

https://en.wikipedia.org/wiki/PDF/A

PDF/A is a small family of sub-formats to PDFs which amount to the accessible subset of PDF + some requirements.

PDF/A and PDF/UA are mandated by a variety of governments for PDF distribution. They're very suitable to archival and are accessible (screenreaders can work with them, their text can be cleanly copied, etc).

Re: The unreasonable effectiveness of simple HTML

#240

Post by aembleton »

allenu wrote: post #178
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.

Years ago I noticed that when I was hungry and tired, I would notice just how much bad design got in the way of completing a task. Things that I would work around easily when I was well-rested and sated all of a sudden became incredibly frustrating. Unclear instructions, or buttons that were hard to find, or error messages that were inscrutable suddenly became very obvious. I posited that it would be an interesting u…

That sounds similar to https://theuserisdrunk.com/

The guy behind the site will get drunk and then test out your website.

Post reply on HN