Live data from Hacker News

Replacing JavaScript with Just HTML

htmhell.dev

221–230 of 296 posts

Re: Replacing JavaScript with Just HTML

#221

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.

Last I checked that without JavaScript details / summary has accessibility issues. That is, you need JS to add aria-open or similar. It’s odd and frustrating that such an essential tag is not defined to be accessible, afaik.

That's not correct. There is no aria-open attribute and the summary implicitly has the correct ARIA state, aria-expanded, indicating that its details element is either expanded or collapsed.

There have been bugs in its implementation, particularly in Safari and differing between mobile and desktop Safari.

Re: Replacing JavaScript with Just HTML

#222
The switch from everything tables to everything divs was one of the worst for usability on the web. Every day I run into a table of data that doesn’t sort, copy/paste, search, resize columns or any of the very trivial items to do with tables. It always infuriating.

Re: Replacing JavaScript with Just HTML

#223

Earlier quoted context omitted.

That is no longer true! You can do it in CSS with a combination of `@starting-style` and `transition-behavior: allow-discrete`. [1] Another gotcha you'll run into is animating the height. A couple other new features (`interpolate-size: allow-keywords` and `::details-content`) will let you get around that. [2] Modern CSS is awesome. [1] https://developer.chrome.com/blog/entry-exit-animations [2] https://nerdy.dev/open…

I can't see how a bunch of esoteric incantations are better than just some straight-forward easy to understand and follow JavaScript.

JavaScript encumbered pages break at least once for NoScript users.

Re: Replacing JavaScript with Just HTML

#224

Earlier quoted context omitted.

Agreed! I assume the reason for the forgetting of the features is that at least some were poorly supported when first released so developers create workarounds that then become the de facto standard. It has been amazing to see the speed up in release and support of new CSS features over the last couple of years! Even the masonry layout has finally reached an experimental stage

Yup, at this point it feels more like habit than necessity. People learned to build things like dropdowns in JavaScript years ago, so they keep doing it that way. A lot of devs simply don’t look any further when it comes to what HTML and CSS already provide.

That exactly describes me. I'm not a good frontend person. I got really, really good at building desktop GUIs in Swing (Java) back in the day and really imprinted on that way of doing things. When moving to web, I found the the display landscape really challenging to grok. I read a few books and got to where I could get most of what I wanted done, but it always took me way longer than it felt like it should, and certainly much longer than it took my coworkers. In that period I learned the contemporary patterns of the day and got pretty good at using component libraries with frameworks like React and was finally able to make things look and behave more like I wanted them to.

Because at that point so much of the focus was on javascript and component libs/frameworks, I didn't (and mostly still don't) really follow browser development. I looked into things like web components when they were first talked about but found their DX to be quite sub-par (it was still pretty early days) and haven't really looked again.

I'm personally much more interested in systems, infrastructure, devops, and all things backend, so for me frontend is a necessary evil to enable me to surface controls for my stuff to users. It's not that I don't want to stay up to speed and current, it's more that in my limited bandwidth I'm more focused on what I care about. That leads to exactly the pattern you described: I learned and got comfortable with a certain paradigm in a different time, and those ways are quite engrained.

Anyway, thank you for your comment. It really helped me identify a blind spot I previously had (which I intend to rectify) :-)

Re: Replacing JavaScript with Just HTML

#225
post #100
post #34

Earlier quoted context omitted.

My main beef with datalist is that there's no easy way to show and allow only text (e.g. Beverly Hills), but have the actual value selected be a number (e.g. 90210). In other words there's no analogy to Beverly Hills .

That and there's no HTML way to interactively load results. Or are you really going to serialize half a million records to HTML and transfer it all every time the relevant block is added to a page? What if it sits in the header or footer templates?

Indeed, and if I have to build a component for it in JS anyway, I'm highly likely to just reuse that component everywhere I need it rather than have to build, style, and test different implementations in the same app.

Re: Replacing JavaScript with Just HTML

#226

Earlier quoted context omitted.

And styling! The default styling of datalists in most browsers is just ugly .

Open an issue with your browser or OS

Default styling being ugly is often for backwards compatibility with older sites so their look stays as consistent as possible. For that reason opening an issue is likely a waste of time for GP and for the devs.

They also are most certainly quite aware of how the default styling looks in their browser. It wasn't an oversight. That's not to say it doesn't pain them, it often does, but it has been intentional

Re: Replacing JavaScript with Just HTML

#227
post #220
post #181

Earlier quoted context omitted.

Is that "straight-forward easy to understand and follow JavaScript" the whole thing written from scratch? Or does it use libraries (that use libraries, that use libraries)? Because I've written my share of javascript-from-scratch in my time - before npm and such. And even if my use-case was limited, in order to get edge-cases and details working - issues long solved by their HTML/CSS counterparts - we needed more and…

using flags for language is a bad pattern I wish would die. I'm not clicking on the British flag!

What about strings + flags?

Re: Replacing JavaScript with Just HTML

#229
post #213

Earlier quoted context omitted.

Note that pure HTML and CSS implementations of tabs using and fail to meet several important accessibility criteria [1]. While you can make something that visually appears to act as a set of tabs, building it accessibly unfortunately still requires JavaScript. [1] https://adrianroselli.com/2019/04/details-summary-are-not-in...

The pure-css effects I mentioned both don't use / .

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

Re: Replacing JavaScript with Just HTML

#230

The interesting part here isn’t “no JavaScript”, it’s that HTML already covers more use cases than people remember (forms, dialogs, validation, navigation). I ran into this repeatedly while writing my book "You Don’t Need JavaScript"[0]: most JS in these cases isn’t adding capability, it’s compensating for forgotten platform features. [0] https://theosoti.com/you-dont-need-js/

Very interesting book! These are the types of programming books I wish that were more abundant rather than "Learn X framework/language," those that solve/discuss interesting problems. Just bought a copy.
Post reply on HN