Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Replacing JavaScript with Just HTML

htmhell.dev

Post reply on HN
Print view View original

91–100 of 296 posts

Re: Replacing JavaScript with Just HTML

#91

Post by crooked-v »

bikeshaving wrote: post #36
crooked-v wrote: post #33

Earlier quoted context omitted.

You can't actually control the open state properly from markup (the `open` attribute only sets the default state), which is why I haven't bothered with them.

I’m not sure this is correct. The DOM class HTMLDetailsElement has the `open` property, which you can use to read/write the details element’s state. If you’re using setAttribute/getAttribute just switch to the property. https://developer.mozilla.org/en-US/docs/Web/API/HTMLDetails...

Having to use the property on the element instance, rather than the actual HTML attribute, is exactly the kind of wrapper code I want to avoid if I'm using a built-in.

Re: Replacing JavaScript with Just HTML

#92

Post by RussianCow »

jakelazaroff wrote: post #61
maxloh wrote: post #45

Earlier quoted context omitted.

> The details / summary thing absolutely kills me. There’s basically nothing you can’t do with them. Animating the details element is tricky. By the spec, browsers don’t natively support transitions between display: none and display: block.

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…

You say awesome, I say layers upon layers of opaque incantations I have to remember. Thank god for LLMs.

Re: Replacing JavaScript with Just HTML

#93

Post by crooked-v »

eleventen wrote: post #35
crooked-v wrote: post #33

Earlier quoted context omitted.

You can't actually control the open state properly from markup (the `open` attribute only sets the default state), which is why I haven't bothered with them.

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.

Re: Replacing JavaScript with Just HTML

#94

Post by swiftcoder »

kmoser wrote: post #34
montroser wrote: post #32

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

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 .

> Each element should have a value attribute... It can also have a label attribute, or, missing that, some text content, which may be displayed by the browser instead of value (Firefox), or in addition to value (Chrome and Safari)... The exact content of the drop-down menu depends on the browser, but when clicked, content entered into control field will always come from the value attribute

This seems... underspecified. Not ideal that Chrome/Safari aren't aligned with Firefox here, and that there is no standard way to only display the label

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

Re: Replacing JavaScript with Just HTML

#96

Post by ozlikethewizard »

xp84 wrote: post #69
qudat wrote: post #46

Earlier quoted context omitted.

Animating accordions is almost always a bad idea because the content length can make it unbearable. In general I find animations on the web overused and unnecessary

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 animated is a reasonable case. You gotta remember your average user isnt paying any fucking attention, so drawing their attention to important changes on screen is not only good but necessary. I'd prefer no animations ever, but i also dont own an iphone while the majority of the world either does or wants to.

Re: Replacing JavaScript with Just HTML

#98

Post by lelanthran »

maxloh wrote: post #45
eleventen wrote: post #8

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.

> The details / summary thing absolutely kills me. There’s basically nothing you can’t do with them. Animating the details element is tricky. By the spec, browsers don’t natively support transitions between display: none and display: block.

> Animating the details element is tricky. By the spec, browsers don’t natively support transitions between display: none and display: block.

Very hot take; then don't animate them!

Animation in a UI is great - you draw the user's attention to a widget that changed because they might not necessarily notice it otherwise. This improves the UX.

With a details/summary, the animation is not needed and can only make a negative change to the UX. There is no positive change to the UX that animating the details/summary elements would bring. When it is opened it is obvious.

If you really really need to animate the details, instead of animating open/close, instead animate the summary background/text color to indicate that the element has just changed state.

Would I like easy animation of open/close? Sure. Does it improve the UX? Nope.

Re: Replacing JavaScript with Just HTML

#99

Post by atoav »

overflowy wrote: post #22

HTML and JavaScript serve distinct purposes, making better or worse comparisons logically flawed. Complex/interactive web apps requires JavaScript, period. Attempting to build sophisticated apps solely through HTML (looking at you HTMLX) eventually hits a functional ceiling.

Depends on how complex it is meant to be. Just like many wordpress sites that could easily have been static websites, many javascript heavy sites could have easily just have been using htmlx.

If your need really, goes beyond what htmx offers, then you may need Javascript. But in my experience people tend to use the tools they know for their job, not the tools that would be best suited.

Re: Replacing JavaScript with Just HTML

#100

Post by tosti »

kmoser wrote: post #34
montroser wrote: post #32

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

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?
Post reply on HN