Live data from Hacker News

Replacing JavaScript with Just HTML

htmhell.dev

261–270 of 296 posts

Re: Replacing JavaScript with Just HTML

#261
post #244

Earlier quoted context omitted.

Same caveat applies to the "checkbox hack" or any other pure CSS solution. You cannot create accessible versions of most complex controls like tabs without JavaScript. (That first example could be created semantically and accessibly with / though!)

for "accessible", do you mean getting focused when pressing TAB key?

Here is a non-exhaustive list of issues you'll run into with various pure HTML and CSS implementations:

- Tabs should have an ARIA "tab" role [1], but doesn't accept roles [2].

- Focusing a tab must activate the corresponding tab panel [3], which requires JavaScript.

- Tabs should be navigable by arrow keys [4], which also requires JavaScript.

I want to be clear that I'm not trying to tear down your work. Your project looks cool and eliminating JavaScript is a noble goal. But unfortunately, as of today, it's still required to correctly build most complex controls on the web.

[1] https://developer.mozilla.org/en-US/docs/Web/Accessibility/A...

[2] https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...

[3] https://w3c.github.io/aria/#tab

[4] https://www.w3.org/WAI/ARIA/apg/patterns/tabs/

Re: Replacing JavaScript with Just HTML

#262

Earlier quoted context omitted.

Same caveat applies to the "checkbox hack" or any other pure CSS solution. You cannot create accessible versions of most complex controls like tabs without JavaScript. (That first example could be created semantically and accessibly with / though!)

what about, make it work in pure html and css, and enrich it with js to make it accessible? rather than not working at all with js disabled

That's actually a common strategy called "progressive enhancement". The only thing is that your order is backwards: you should first make it accessible in pure HTML and CSS, and then use JavaScript to layer your fancy interactions on top.

So, for the tabs example, your baseline pure HTML and CSS solution might involve showing the all tab panels simultaneously, stacked vertically. Once the JavaScript loads, it would rearrange the DOM to hide all but one and add the tab-like behavior.

Re: Replacing JavaScript with Just HTML

#263
post #69

Earlier quoted context omitted.

Seriously. As a user I can count on zero hands the number of times I’ve said “Oh great, I’m sure glad this UI is animated!” - and likewise zero times have I missed it when animation isn’t used. Animation is a way to light small units of your users’ precious time on fire, for zero benefit.

As the other user alluded to, Animations are not actually there for people who are comfortable using a computer. The vast majority of users are borderlines in capable of using the internet these days. Animations are supposed to be there to really help guide these users into understanding what the scary machine is doing when they click it. Can they be overused, absolutely, but i think have an accordion fold out animat…

If it is for those people who barely grasp the slightest thing about what’s going on on-screen, I could grant them that, if they’d let me turn it off. In the days before jailbreak became basically impossible, setting the animation duration to zero was a blessed, incredibly satisfying thing. It’s exactly what I want. Just do the transition in zero seconds.

My iPhone 15 can’t even catch my first 1-2 keystrokes on the keyboard, multiple times a day, but boy howdy does it have the time and the cycles to animate that f*%ker into view. The disrespect for my time and my needs is so obvious.

Re: Replacing JavaScript with Just HTML

#264
"Nothing against JS, but it has better things to do than setup and manage your accordions or offscreen navigation menus... "

Perhaps this is referring to "things" such as data collection, surveillance and ad services

It would be interesting to see how Big Tech and other adtech companies would accomplish the same level of data collection, surveillance and ad services without the use of Javascript

As for "nothing against JS", I think some web users (cf. "developers") who dislike adtech and the ad-laden web they perpetuate might have something against it

Re: Replacing JavaScript with Just HTML

#265

Most of this is great, except for the input/datalist bits, which are not sufficiently functional to be used in any real scenario. Users expect these interfaces to be tolerant of misspellings, optional sub text under each option, mobile ux niceties, etc -- and so everyone builds this with js...

Also datalist is nice but most the time we need a “select” (so users can’t submit anything not in the list), but select doesn’t have search/filtering like datalist has.

Re: Replacing JavaScript with Just HTML

#266

Earlier quoted context omitted.

Yeah this is true at this point. A lot of more complex patterns require JS to be accessible to screen readers. We still should do more with HTML and CSS! And reach for leaner solutions than React everywhere. But be careful going for a pure CSS solution for things like tabs if you don’t understand the accessibility requirements. (I wish the HTML spec would move faster on these common patterns!)

> We still should do more with HTML and CSS! And reach for leaner solutions than React everywhere. It's pretty difficult for anyone to completely understand all the nuances in HTML and CSS. It's a big mess that gets bigger and messier every year. We should have just given JavaScript even more power over controlling the viewport and leave HTML and CSS for the history books.

Because JS isn’t a big mess?

Re: Replacing JavaScript with Just HTML

#267

Earlier quoted context omitted.

Out of curiosity, why have you needed to? This has never come up for me.

For a simple example, imagine buttons that opens a modal with a particular arrangement of open/closed accordions for each button.

You can do that with a details element, you just need some code to actually do it. Which I'm pretty sure there's no possible solution that doesn't require some code to do that.

Really don't see what your complaint is.

Re: Replacing JavaScript with Just HTML

#268

Earlier quoted context omitted.

> We still should do more with HTML and CSS! And reach for leaner solutions than React everywhere. It's pretty difficult for anyone to completely understand all the nuances in HTML and CSS. It's a big mess that gets bigger and messier every year. We should have just given JavaScript even more power over controlling the viewport and leave HTML and CSS for the history books.

Because JS isn’t a big mess?

Yes. But first lets reduce the mess from 3 big mess technologies to 1 and then we can working on replacing JS.

Re: Replacing JavaScript with Just HTML

#269

Most of this is great, except for the input/datalist bits, which are not sufficiently functional to be used in any real scenario. Users expect these interfaces to be tolerant of misspellings, optional sub text under each option, mobile ux niceties, etc -- and so everyone builds this with js...

Also datalist is nice but most the time we need a “select” (so users can’t submit anything not in the list), but select doesn’t have search/filtering like datalist has.

Technically native selects do have a very rudimentary form of filtering: start typing text with the select focused and it will auto-select the first matching option.

E.g. if the select is a list of US states, type "N" and it will jump to Nebraska. Continue into "New" and you'll get New Hampshire, etc.

This is better than nothing (and I personally use it all the time) but not a patch on an actual proper select-with-filtering which, yes, you still need JS to implement properly.

Re: Replacing JavaScript with Just HTML

#270

The details / summary thing absolutely kills me. There’s basically nothing you can’t do with them. Hiding and replacing markers is easy. But every component library just pretends they don’t exist. It even saves you the effort of all the aria control and expanded tags: these tags don’t need them.

When you search text with ctrl+f it also searches inside details elements and automatically expands them!

Ooh, that sounds useful as a pretty mix-in-bad-data method for scrapers. Have a few of these tags do if junk, even though they are hidden it'll look to a scraper that cares about hidden/not like they aren't always hidden so are likely to contain something worth adding to their DB…

I'd need to look into what effect this might have on accessibility, but my gut says "very little".

Post reply on HN