Live data from Hacker News

The unreasonable effectiveness of simple HTML

shkspr.mobi

311–320 of 387 posts

Re: The unreasonable effectiveness of simple HTML

#311
post #187

Earlier quoted context omitted.

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

Greyed out because there is no video location for you to view or save. It’s playing a stream, put together from many pieces, so that it performs and functions better.

Switching between sources mid-play is a lot harder than most realise, because random seek is expensive in videos. So instead you tend to treat it as a large number of files of a few seconds each that get glued together as you play it, and you can switch between them as you go.

The web platform could be extended to cover multiple-bitrate streaming and let the browser take control, but that’s a pretty complex affair, and I suspect that it still wouldn’t be enough to make these operations work—the browser would need a way of putting it back together again into one file.

Re: The unreasonable effectiveness of simple HTML

#312
post #68
post #19

I am not a front-end developer but looking at it from a distance I really don't get modern web design. Sure some sites might need fancy javascript single page features, like if your webpage is an interactive map or realtime game, but most sites are just text and some pictures. Whats with all the javascript? Your site looks just like the next one anyway! It feels like an "Emperor's New Clothes" situation or maybe more…

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…

Oof. Yeah, I am now very glad I got out of that game, does not sound like a nice place.

SPAs were for a specific, narrow, set of use cases where it really didn't make a lot of sense to even have a backend...

Companies don't really have the incentive to build good software, though. Fads and cargo cult 'lets use this popular BS' tend to catch on more when the name of the game isn't software, rather its about pandering to a job market. Outside of sudden and painful corrections that market seems to promote bad engineering, probably because it costs more over time to maintain and thus creates more demand in a 'negative' positive feedback loop...

Trying to legislate it back in by pointing out that most sites are hot piles over garbage that are unusable by anyone with any sort of impediment (physical, technological) seems like a nice idea, I don't see much growth in that area anyways so perhaps it is time for strict law enforcement...

Re: The unreasonable effectiveness of simple HTML

#313

Earlier quoted context omitted.

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…

You can: have an “insecure.” version of your site, like people used to have a “secure.” version.

You can’t:

① If it’s on the same domain, it would necessitate weakening the HSTS policy, removing includeSubDomains and preload.

② If it’s on a separate domain, you’re actively training people to do dangerous things and get phished.

③ Pretty much the only way this will ever be used is if you push people to it and ensure that search engines choose it rather than the secure version. (Implicit in this is a significant SEO hassle.) Thus you’re back exactly where you started.

Re: The unreasonable effectiveness of simple HTML

#314

Earlier quoted context omitted.

You original point > the Javascript ecosystem is unmatched when it comes to very quickly creating frontend applications Didn't hinge on whether you were creating internal tools or not. You simply used internal tools as an example of what you personally do with JS.

I see your point, and I agree it's definitely not a good solution to some problems. But I think it can be very productive if your constraints allow you to use it.

That would be fine if the attitude were 'best tool for the job'...

Often there is the people element to tech though - that isn't the attitude, normally optics is your tech wiz kid is doing something cool with (metaphor) peanut butter sandwiches, lets build our next office complex with peanut butter sandwiches. Architecture? What's that. Move fast, break things, eat lots of sandwiches.

Re: The unreasonable effectiveness of simple HTML

#315

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…

You can't prevent a downgrade attack on server side, the attacker can simply roll full HTTP on top of your server. And browsers already disallow or warn against submitting passwords over HTTP, is there a problem to fix there? Browsers disabled old versions of TLS, you don't harm anyone by supporting them (except for bit rot of that old code). There are also sites with zealous TLS settings, they support only sha384 cypher suites and nothing else at all.

Re: The unreasonable effectiveness of simple HTML

#316

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

Does not even have to be that grim/profound.

Ever used your phone in the blazing sun, or rain? Had a partly shattered screen or tried to do something on the stone-age library computer? Searched for something with really slow or shaky connection? Tried to explain where to click via phone?

Suddenly all those accessibility features and "fail gracefully" come in really handy.

Re: The unreasonable effectiveness of simple HTML

#317

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

It's often put as "temporarily abled" or "able-bodied".

    "We're all just temporarily abled."
is quite famous quote, as far as I traced attributed to Cindy Li.

Re: The unreasonable effectiveness of simple HTML

#318
post #176

Earlier quoted context omitted.

I find it much worse that so many sites nowadays expect users to have their browsers maximised. Noticed how most books aren't wider than an A5, and how any publications wider than this use relatively narrow columns? Because reasonably narrow text is easier to read.

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 window managers. Windows 7 and before definitely didn't make it obvious how to make a window half a screen, Windows 10 makes it a bit more obvious I think, but you're still limited to 2 windows side by side. Ubuntu's default window manager has the same behaviour as W7 and Lubuntu's doesn't have keybindings for this by default at all.

You can of course resize windows manually but it's tedious compared to a 2 button shortcut, especially having to hunt the 3 pixel wide resize button with wrist issues.

Re: The unreasonable effectiveness of simple HTML

#319
post #113

Earlier quoted context omitted.

ISPs regularly MITM http websites to inject ads (in the US even).

It happens. I think I'd rather my site be served with ads, than not at all. It would be great if we could always automatically choose the right option, but browsers don't do that.

Ads aren't that much of a problem, but serving cryptominers/phishing websites/viruses is a real issue.

Re: The unreasonable effectiveness of simple HTML

#320
post #154

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.

Line width is approximately equal to browser window width, so you can adjust the line width by resizing the browser window.
Post reply on HN