Hacker News Reader

Comment by intergalplan | Hacker News Reader

There's so much stuff in HTML that's almost good enough to replace things we use Javascript for. We should also have had built-in pagination and sorting on tables, like, years ago, with some kind of (optional, if your data aren't all available on the initial page load) back-end spec for how the requests will be shaped and for delivering the data.

An awful lot of "AJAX" Javascript use could just be frames and iframes, if they were somewhat better.

Form validation should be built-in (with optional light JS for defining non-built-in validators). The browser should supply a lot more input types, including some kind of payment integration. It's absurd those things have to be built over and over and delivered by the website.

I could go on. It's a damn shame.

View on HN

The HTML form <input> element has a lot of interactive controls already e.g. colour picker, a date control for entering dates, file picker, number entry with spinner controls and more:

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in...

The problem is that some HTML form controls cannot be styled with CSS to render consistently across browsers. So, many sites fall back on JavaScript to render the control. Here is an example from 2016 on styling HTML checkboxes and radio buttons to make them larger (which, as far I can tell, is still a problem): https://designnotes.blog.gov.uk/2016/11/30/weve-updated-the-...

Date pickers and color pickers don't have to be consistent across desktop/tablet/mobile/kiosk/etc. They just have to be consistent across sites, but on the same device.

On Firefox, the date picker is good and I can easily navigate to a year from muscle memory. The same wouldn't work on mobile, so they have different UI and controls. I don't want to use iOS style date pickers on my Android, or the other way around just for consistency.

Many custom date pickers are sluggish and has bad UX, and adds a lot of extra validation complexity with pseudo elements.

And also cross browser support for the spec in general - eg desktop Safari doesn't implement that date picker, or any special treatment of input type="date" at all.

I don't have a modern Safari in front of me to check, but Can I Use alleges they're about on par with Firefox as of 14.1: https://caniuse.com/?search=Input%20date

Does that mean only fully up-to-date macOS gets it, or do Safari versions move independent of the OS?

Current Safari is available on at least two previous versions.

In rare cases, Safari features require a capability only available on the latest macOS.

Apparently it will be supported in the next version! https://webkit.org/blog/11648/new-webkit-features-in-safari-...

In fact, Safari 14.1 is current as of last week (well, this week...) https://support.apple.com/en-us/HT212340

And iOS 14.5 (well, 14.5.1) is also current: https://support.apple.com/en-ca/HT211808#1451

But we'll have to wait a few weeks to months before all Safari users upgrade and see the latest improvements.

Yes, but still I think it's great news as it looks like we can realistically make forms using native inputs only and validation, complex inputs (like date pickers) all can be setup with little to no javascript. This enables much simpler architectures, like traditional server side rendered apps, that still have a great UX.

In Python there's a saying: the standard library is where modules go to die. That effect applies even more so for browser builtins.

IMO we would be better off moving most of these things out of the browsers and into some kind of web component standard.

Yeah, I’ve long thought that the model of a relatively sparse standard library in a sufficiently expressive language is the ideal. What’s really needed is a newspeak-style parameterized “push” module system (or ML functors) to replace “pull”-style imports.

This way, modules can declare that they need certain functionality and then the end user provides it: instead of npm-style infinitely-deep dependency trees.

https://gbracha.blogspot.com/2009/06/ban-on-imports.html?m=1

https://wiki.c2.com/?BanOnImports

no way, browsers have a stacked deck especially in regards to accessibility, but also things like platform appropriateness and handling corner cases that only affect specific scenarios. web components tend to be the 80% that whoever made them cared about, which varies from use case to use case.

It's also because Python has such an awesome stdlib that it's so popular. So there is that.

> Form validation should be built-in

Have you used pattern attributes?

https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes...

Yes! That is definitely a big step in the right direction. It's usually enough to remove at least some of the JS burden on forms. I'm not sure how widespread its use is in practice, though.

I know it uses JS but the customValidity stuff is pretty cool too!

and the :invalid css option (I like to just make the bottom border red, dashed)

FYI now there’s also :user-invalid which waits for the user to blur out of the field before it indicates the validity.

drag and drop rearrangeable lists as a form element!

Business users looooove drag and drop. I've seen products burn a stupid amount of money to have it, and decision-makers insisting it was a must-have no matter the cost in time and ongoing overhead in time & bugs for everydamnthing else added to the UI after. I've seen business-side people favor terrible products because they have drag-n-drop, while a better alternative doesn't. They love it.

It's heavy-weight, fragile, lots of implementations are framework-specific, and most of them are horribly buggy, but it's nonetheless a must-have feature in many cases. It'd be a great candidate for better support in the browser, generally, if we're going to insist on using it as an application platform.

> Business users looooove drag and drop. I've seen products burn a stupid amount of money to have it, and decision-makers insisting it was a must-have no matter the cost

This just made me laugh because it is so true. I thought it was just my stupid luck that I keep working with companies obsessed with drag and drop. But you are right. I have seen companies blow hundreds of thousands of dollars implementing drag and drop on a trivial feature. The same company will then complain about spending a few thousand dollars implementing a security feature or implementing training programs to teach employees about the importance of securely handling PII.

Edit: PII = Personal Identifiable Information (social security numbers, credit cards, birthdates, etc).

Has this improved? I've seen recently browser built in drag and drop (that people don't use as of, but as a base in lightweight dnd librairies).

I don't remember having that last time I had to implement serious drag and drop, about 4 years ago.

Drag and drop is not actually very usable. It's nice to have it as an option, but the main approach to rearrangeable lists should just be a list widget w/ selectable items and [↑] [↓] buttons to shift the currently-selected entry upwards or downwards.

I strongly disagree. It’s the most natural thing in the world for GUI/mouse users to drag-n-drop objects. It’s even nice for touch with the right OS/hardware support.

You are confusing "usable" with "intuitive".

You are both right. Drag and drops are incredibly intuitive for users. It feels natural to most people and is easy for many of them to use.

But the parent comment is also right because drag and drops are not very USABLE. Meaning that if someone is using a screen reader or an unusual device (phone, kiosk, kindle, etc) the drag and drop functionality may not work well for them or might not work at all. It might be INTUITIVE on what the user is supposed to do, but it isn't USABLE. We have all encountered non-usable interfaces that we simply can not interact with for various reasons. This also becomes a concern for accessibility. A screen reader may not be able to read it to someone who is blind. An older device might not be able to display or operate the drag-able functionality. A user that relies on something like "Voice Control" may not be able to use your drag-and-drop system.

Ideally you would do both. You could show an interface that has up and down arrows for each item to move items manually. But also make those elements drag-able if users choose that option. But this takes more and more development time. That is the constant battle between software engineers and decision makers. Anything is possible with enough development time, but decision makers are quick to move developers along when the item is "good enough", which generally means the feature works on the decision-maker's devices.

that just sounds all the more reason for a drag and drop thing to be implemented as a standard form element, that way browsers/screen readers can provide an accessibility fallback. whereas with javascript widgets, that's unlikely to happen quite often. and people are going to do drag and drop interfaces no matter what

Reply on news.ycombinator.com