Live data from Hacker News

Replacing JavaScript with Just HTML

htmhell.dev

171–180 of 296 posts

Re: Replacing JavaScript with Just HTML

#171

Earlier quoted context omitted.

It'll just degrade gracefully into not animating the element's entry, so unless the animation is somehow crucial you should still be fine to use it. If you really need to detect whether it's supported there are hacky methods: https://www.bram.us/2024/07/11/feature-detect-css-starting-s...

I agree, but must also observe that I have never met a designer who was willing to admit without a knock-down drag-out fight that any animation they put in was not somehow crucial.

I've never met a designer who wasn't completely fine with my suggestions for more pragmatic solutions. Like just styling a default scrollbar instead of implementing my own scrollbar to make it exactly like the design. Using a default drop-down menu instead of rolling my own just so I can round the corners of the selects.

The designers I've worked with are fine with these things. We have more important things to work on than small style details. We can go back and change these things later if anyone actually cares, but generally nobody ever does.

Re: Replacing JavaScript with Just HTML

#172

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…

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

You're doing it wrong. You don't have to remember the incantations. You just have to remember that they exist, and then google them or ask an LLM when you need them.

If you use something enough you'll remember. If you don't, you just look it up when you need it. This is basic programming, nobody remembers everything.

Re: Replacing JavaScript with Just HTML

#173

Earlier quoted context omitted.

OT: marquee tags were a missed opportunity to implement horizontal scrolling often used on shopping websites. Now it uses JS to achieve the same. I have been trying to find other more commonly known UI patterns that could be done natively. The time has long come for tabular data to be put into HTML tables just by referencing the source. Xslt almost did that. Another one is integrating xml http requests with native ht…

There's a usability and design issue with that as you lose what you're reading as it scrolls off the screen. Also, scrolling is a styling issue and not a document description issue which is what HTML is for. Note: has never been part of any HTML standard since the beginning except the current one which only has it for the purpose of marking it obsolete so people will quit using it.

[deleted]

Re: Replacing JavaScript with Just HTML

#174
post #169

Earlier quoted context omitted.

One drawback of details was that cmd+f search wouldn't play nicely when the details was closed. But now there's a hidden="until-found" you can put on child content, along with an associated event. So you can open the details when a user searches :) super useful

You don't need the hidden="until-found" for details/summary, because that has those semantics automatically, but you can use that for other elements that behave similarly (for example tabs, which can't quite correctly be implemented with details/summary, and so needs to be done by hand). Also I think the event isn't currently emitted consistently on all browsers (and maybe not at all for hidden="until-found"?) so unf…

Oh huh I didn't know details supported that naturally. I'm guessing this wasn't always the case and my knowledge is simply outdated. TIL!

Re: Replacing JavaScript with Just HTML

#175
post #83

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.

If you specify the same name on each `details` element they behave like an accordion automatically [1], no need for JavaScript. If you set one of them to open that one will be initially open. [1] https://developer.mozilla.org/en-US/blog/html-details-exclus...

different things with the same name? O_O

Re: Replacing JavaScript with Just HTML

#176
post #145

Just been through several frontend interviews in the last few months, where it's clear that they still judge a developer's JS skills (especially React) than being semantically correct on HTML elements. Every question/exercise is centred around how well you know React hooks, effect, memoization, modern css-in-js etc. Given I've been working with Astro recently, in one interview I talked about DOM APIs and I can see th…

Remember that a large part of hiring is finding someone who fits in an existing team. A team that uses react won't appreciate someone choosing to use native DOM APIs instead of a react component.

Eh. I build apps with Preact, but I prefer candidates who know the core web platform. They’ll be more apt to use the right tool for the job and not be baffled by edge cases.

Re: Replacing JavaScript with Just HTML

#177
i like the points the article makes, but i really wish it used looping videos instead of actual GIFs

i don't really see any reason to use GIFs here; any widely available video codec like H.264, VP8/VP9 or AV1 will result in significantly smaller file sizes, look better, and will allow enabling controls for seeking and play/pause

Re: Replacing JavaScript with Just HTML

#178
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…

The major issue with this is that modern CSS is almost its own job, to the point we used to have Interface Developers at some place I’ve worked (HTML+CSS specialists). I did frontend for over a decade and eventually lost the train on CSS changes, I don’t even know what’s going on there anymore.

It’s still awesome, but it’s becoming increasingly silly to ask someone to know modern HTML, CSS, JavaScript, Typescript, some build tools, a couple of frameworks, etc.

The amount of JS we ship to clients is a reflection of cost-cutting measures at your workplace, not that every FE dev shuns CSS.

Re: Replacing JavaScript with Just HTML

#179
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…

That's the positive interpretation, but none of the discussions I've had with UI designers or managers have been about adding animation for accessibility, and the zeitgeist of the last decade has been that skeuomorphism (of which intuitive animations are a subset) is passé.

So far as I can tell, all that the stakeholders want from the UI, animations included, is pizzazz.

Re: Replacing JavaScript with Just HTML

#180
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?

Right, I sort of expected there to be an attribute for an url.

   
But then you would want to send other form values along with it which might make things more complicated than it should be?

Static could be better too. When search engines first started building these auto complete dropdowns the multi word input was really the killer feature. To have something like "green toyota" you would have to generate an element for all color and brand combinations? And the you want it to work for "green toyota corolla" and you get an abc kind of list length.

Perhaps a wildcard would have been fun or regex options.

  
  
  
Post reply on HN