Top
Best
New

Posted by encyclopedism 1 day ago

HTML Can Do That(chrisburnell.com)
487 points | 142 commentspage 4
teddyh 5 hours ago|
See also: <http://youmightnotneedjs.com/>
br0ceph 2 hours ago||
js is web remote code execution. we need to return to an html only browser world.

theres no reason for a browser to be an OS/compiler/abi, for remote code.

this is the dumbest shit in the history of computers. why didnt everyone have they torches and pitchforks, when web2.0 became a thing?

mabini 6 hours ago||
Just because you can, it doesn't mean you should
abanana 1 hour ago||
Although I've used that phrase myself in the past, I've come to hate it. Somebody will post it on every HN thread where any form of suggestion has been made.

If it's part of a paragraph of insightful commentary, it's meaningful. On its own it's not, it appears as though the poster chose to copy-and-paste a cliché instead of bothering to tell us what their specific disagreement even is (perfectly reasonable sarcasm from the sibling comment notwithstanding).

Aachen 5 hours ago||
Exactly. Why reïmplement features in JS just because you can? Waste of effort and usually a worse user experience!

Wait, that wasn't what you meant?

metalliqaz 4 hours ago||
What on Earth is hidden-until-found for?
totallygeeky 22 hours ago||
I've been tooling with site for years now and I'm always shocked at what can be done with raw HTML. These are some really neat examples, some work a bit funny when it comes to mouse vs. arrow key functionality though (in particular the dropdown/autocomplete), I'm wondering if that's an Edge specific issue or Chromium.
encom 5 hours ago||
>popover

Why are we cool with popups again? Anything that interrupts and blocks content is annoying, and is nearly guaranteed to make me leave immediately. It can be used responsibly, but it almost never is.

vazark 5 hours ago|
It is commonly used in dashboards when you want a confirmation dialog
bellowsgulch 6 hours ago||
The older I get, the less I want to use new browser features that have already been somehow possible with existing ones that typically have been around for literal decades.

Adopting them makes a future with multiple browser engines more labor intensive and unlikely as the number of standards targets one is required to support grows and it becomes a game of asking yourself what sites you want your browser to support.

If you don't have a lot of experience in web software, you might think, that's a silly thing to think about, but I think it's that level of maybe exceptional thoughtfulness that has really profound ramifications. If you do have a lot of experience in web software and you think it's silly to think about, you suck.

abanana 50 minutes ago|
You started that off by raising an interesting point. Pity you had to ruin it by telling us you're exceptionally thoughtful and profound, and that those who disagree, suck!

It's true, the amount of work that would be needed nowadays has made the idea of building a new browser engine almost impossible (I don't know how the Ladybird devs are getting on). It's a reason to encourage people to support Firefox on desktop, since just about everything else is based on the other browser engine. I still miss Opera's Presto - we don't want to lose another one, or there'll be no competition at all.

But as we've already crossed that threshold where the workload is preventing new engines from being built: choosing not to use new features, after they've been added to all the existing browser engines, isn't going to help that situation in any way.

zuzululu 4 hours ago||
ngl i was surprised for the modal dialogs i always thought we needed javascript as i have been doing so forever with jquery

a bit off topic but wish we could bring back <frames> and <tables>. just good old fashioned stuff from the late 90s

yurishimo 23 hours ago|
Just a heads up but datalist is not really a great solution if you need a strong contract. The user can still type whatever they want into the field and there is no fuzzy filtering or typo mitigation. Once you add those requirements, a library that gives you a more fully featured combobox is likely going to make a lot of sense in your project.
vlucas 7 hours ago||
Very true, and ran into this one specifically myself when going down the "HTML can do this!" road. HTML can NOT, in fact, replace a good combobox with search input. Datalist has significant shortcomings. I wound up using a React island for this single input inside otherwise normal HTML, despite my own objections, because it really it just that much better than the native options.
Groxx 5 hours ago|||
Wow, yeah - years later and I still get nothing in Firefox, and support is quite spotty in general (and clearly still buggy): https://caniuse.com/?search=datalist

Hard pass, that's essentially unusable.

sarchertech 7 hours ago|||
There’s still browser/OS typo mitigation.
reaperducer 7 hours ago||
That's the whole sanitize vs. validate argument debate that keeps coming up.

How you handle it is project-dependent. But if you're doing a real web site, not an SPA, you can show an error/help page, or re-load the current page with the error/help message.

yurishimo 5 hours ago|||
For sure; and it will continue to be an issue as long as we allow old browsers to exist. I’m definitely not saying you shouldn’t have backend validation, just highlighting where the frontend validation provided by the browser is not as universal as it might appear on the surface.

FWIW I find the native date picker to also still be quite poorly performing in practice, despite quite robust browser support. I wish it worked better but for many reasons, I still see plenty of users (or bots?) who submit dates in the wrong format for whatever reason. My current hypothesis is largely focused on password managers though since they will often do whatever they want directly in the value attribute of an input element.

Arch-TK 5 hours ago|||
This is specifically about good UX not about security, validation, or sanitisation.
More comments...