[HN Gopher] Replacing JavaScript with Just HTML
___________________________________________________________________
Replacing JavaScript with Just HTML
Author : soheilpro
Score : 669 points
Date : 2025-12-28 01:07 UTC (21 hours ago)
(HTM) web link (www.htmhell.dev)
(TXT) w3m dump (www.htmhell.dev)
| theandrewbailey wrote:
| > Input with Autofilter Suggestions Dropdown
|
| It's great until you have a typo in the field, or want to show
| options that don't start with what you typed in but appear near
| the end of an option (think Google search's autocomplete).
| There's no way to filter in Javascript and force it to show
| certain options with <datalist>. I've resorted to <ol> for search
| suggestions.
| prisenco wrote:
| When building out a new app or site, start with the simplest
| solution like the html-only autofilters first, then add complex
| behavior later.
|
| It's good to know these things exist so there are alternatives to
| reaching for a fat react component as the first step.
| willparks wrote:
| It's great to see practical examples that push us to consider
| what the platform already offers before adding more layers of
| complexity.
| zdragnar wrote:
| Until your client tells you that it doesn't work in Edge and
| you find out it's because every browser has its own styling and
| they are impossible to change enough to get the really long
| options to show up correctly.
|
| Then you're stuck with a bugfix's allotment of time to
| implement an accessible, correctly themed combo box that you
| should have reached for in the first place, just like what you
| had to do last week with the native date pickers.
| prisenco wrote:
| Right, don't add complexity until you have to.
| abustamam wrote:
| I'd argue that adding complexity from the get-go to ensure
| that all users have a pleasant experience from the get-go
| is better than simplicity at the expense of some percentage
| of users.
|
| I think it's important for web devs to spend more than two
| seconds to think if the complexity is necessary from the
| get-go though.
| smlavine wrote:
| The Pentagram at the top of the page does not load without JS
| enabled.
| bitbasher wrote:
| So it's.. fitting, how meta.
| superkuh wrote:
| Some of these new HTML features don't fully work in my "ancient"
| browser. But all of them partially work (ie opening the accordion
| element doesn't close others but it still opens and closes) and
| they still remain functional elements I can read and interact
| with. This puts them far ahead of any javascript implementation
| which almost universally fail to nothing.
| ravenstine wrote:
| What "ancient" browser are you using?
| vpShane wrote:
| Probably something 300 CVEs ago.
| subdavis wrote:
| 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.
| webstrand wrote:
| Details works even when it's set display:contents too, for even
| more flexibility. Can't animate from open>close, yet, though.
| That's pretty much my last frustration with it.
| shakna wrote:
| I think the CSS support for that has finally landed, though
| it means targetting a pseudo element instead. Its been a
| year, so support is probably good enough you don't care if
| just the animation doesn't happen.
|
| https://developer.chrome.com/blog/styling-details
| lelandfe wrote:
| Note that the transition to `auto` in that post relies on
| `interpolate-size` which has yet to land on Firefox or
| Safari, and neither have movement right now.
| raybb wrote:
| Do they work well for when you want to preview text? Like show
| the first 100 characters of a paragraph and then click to
| expand?
| veqq wrote:
| Of course. That's the summary part
| zahlman wrote:
| Yes. For example, on Codidact (https://codidact.com), limited
| HTML access is offered along with Markdown when making posts,
| and the details and summary tags in particular are
| whitelisted. I've made extensive use of this in some of my
| content, for example https://software.codidact.com/posts/2892
| 51/289252#answer-289... . If you have NoScript you can easily
| verify that the expanding sections work perfectly well
| without JavaScript. They can even be nested, as they are
| here; and the summary text can contain some other forms of
| markup without issue. (When crafting the post, however, I had
| to do some tricky things with whitespace to avoid confusing
| the Markdown parser.)
| crooked-v wrote:
| 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.
| subdavis wrote:
| Out of curiosity, why have you needed to? This has never come
| up for me.
| crooked-v wrote:
| For a simple example, imagine buttons that opens a modal
| with a particular arrangement of open/closed accordions for
| each button.
| bikeshaving wrote:
| 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...
| crooked-v wrote:
| 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.
| _heimdall wrote:
| What kind of control are you looking for?
|
| `open` works just like checked for a checkbox input. You
| can set the initial state in HTML and CSS can respond to
| changes in the attribute if a user clicks it. Markup
| won't have programmatic control over the attribute by
| design, that's always done in JS by modifying the element
| instance.
| WickyNilliams wrote:
| You need some JS to change an attribute as much as you
| need JS to change a property. What am I missing?
|
| I hope the command attribute
| (https://developer.mozilla.org/en-
| US/docs/Web/HTML/Reference/...) will eventually support
| this out of the box. In the meanwhile you can write a
| single custom --toggle command which is generic and works
| with any toggleable element
| rhdunn wrote:
| 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...
| crooked-v wrote:
| It's not about using it as an accordion, it's about
| controlling the open/closed state from other interactions.
| 6510 wrote:
| different things with the same name? O_O
| wartijn_ wrote:
| It's the name of the accordion and matches how radio
| buttons work. If you want to distinguish them, you'll
| give them different ids.
| maxloh wrote:
| > 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.
| qudat wrote:
| 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
| xp84 wrote:
| 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.
| normie3000 wrote:
| Animations are also a way to explain causal relationships
| between interactions and their results, and to help build
| mental models of software behaviour.
| TeMPOraL wrote:
| Being related to neither software behavior nor the
| structure of the underlying problem, animations tend to
| _obscure_ the causal relationships and make it harder for
| user to build a correct mental model.
| kaoD wrote:
| I see where you're coming from: animations are overused
| and even when they make sense they are made too slow and
| flashy (because otherwise how would the implementors feel
| like they did something if it's barely noticeable?)
|
| Animations are like bass in music: most people notice
| them only when they're missing or bad.
| ozlikethewizard wrote:
| 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.
| ben_w wrote:
| 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 passe.
|
| So far as I can tell, all that the stakeholders want from
| the UI, animations included, is pizzazz.
| jakelazaroff wrote:
| 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-and-close-transitions-for-the-
| details...
| llmslave2 wrote:
| @starting-style Has less than 90% browser support making it
| a non-starter for the time being at least.
| jakelazaroff wrote:
| 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...
| bryanrasmussen wrote:
| 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.
| mikedelfino wrote:
| The trick is they'll see it working for themselves. :)
| sfn42 wrote:
| 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.
| bryanrasmussen wrote:
| I've never met a designer who cares how it gets done but
| I have hard time believing they were OK with the corners
| not being rounded as per the design. They may agree on
| shipping without the rounded corner, as long as the
| ticket to round that corner is registered.
|
| I suppose though that we have just had very different
| life experiences, as that is what the HN guidelines would
| require of us.
| whstl wrote:
| I think you're both right.
|
| I have also met a lot of completely unreasonable
| designers that would insist on the most minimal things
| (even to the detriment of usability), and would act like
| assholes towards developers.
|
| I have also had situations where developers would beg to
| work with a certain designer because their experience
| made development a breeze, even for complex layouts.
| Funny enough, the projects where this designer worked
| would always get done, and the visual result was always
| great.
| llmslave2 wrote:
| It depends on what you're doing. It's common for clients
| to wonder why the design they saw had fancy animations
| yet they don't see them on their MacBook...
| paulddraper wrote:
| 91% of usage for browsers tracked by caniuse [1].
|
| The biggest gap is Chrome versions > 2 years old.
|
| [1] https://caniuse.com/?search=%40starting-style
| RussianCow wrote:
| You say awesome, I say layers upon layers of opaque
| incantations I have to remember. Thank god for LLMs.
| nchmy wrote:
| And how might you do this in Javascript?
| bryanrasmussen wrote:
| they just said "LLMS"!
| nchmy wrote:
| My point was that js would be vastly more complicated
| than these html/css "incantations".
| davidmurdoch wrote:
| Most front end engineers could do it in JS without ever
| having to look something up. But the CSS to do it is
| still obscure to most.
| nchmy wrote:
| so, why not answer my question and say how you'd do it in
| js...?
| pikuseru wrote:
| "Layers upon layers of opaque incantations"
|
| You've described software.
| sfn42 wrote:
| 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.
| wvenable wrote:
| I can't see how a bunch of esoteric incantations are better
| than just some straight-forward easy to understand and
| follow JavaScript.
| yurishimo wrote:
| Because you need 20x the JS to do the same thing and it's
| still not hardware accelerated. These new CSS properties
| are well supported and will only get better.
| paulddraper wrote:
| 1. CSS is declarative, so it avoid subtle bugs
|
| 2. CSS integrates better with HTML, as it has selectors
| to automatically bind to elements (yes there custom
| elements for JS)
| onion2k wrote:
| JS animations run on the main thread with everything
| else, so if your browser is busy doing something else the
| animation ends up being janky. Using CSS solves that
| problem.
| dekoidal wrote:
| Is CSS too hard to learn or something?
| pikuseru wrote:
| Because a team of browser engineers have already written
| and reviewed the code to do it for you; and (hopefully)
| it'll be performant, properly tested and accessible...
| ;-D
| berkes wrote:
| 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 more JS. Many of which
| handwritten polyfills, agent-detection, etc.
|
| Seriously, things like scrollbars (because the client
| insisted on them being consistent across user-agents) or
| dropdowns (because they had to be styled) "visited" state
| on links, in pure JS are thousands of lines of code.
| Maybe not today, anymore, IDK, with current APIs like the
| history API or aria labeling. But back then, just in
| order to make the dropdown work with screen readers, or
| the scrollbars react well to touchpads -in the direction
| the user was used to based on their OS- took us thousands
| of lines of JS, hacks, workarounds and very hard to
| follow code - because of the way the "solutions" were
| spread out over the exact right combination of JS, HTML
| and CSS. Edit: I now recall we got the web-app back with
| the comment "When I select "Language" and start typing
| "Fr" I expect French to be picked and "enter" to then put
| the language in French". We spent another few days on
| functions that collect character inputs in memory and
| then match them with values. All because "flags in front
| of the names were of crucial importance".
|
| So, maybe this is solved in modern HTML/CSS/JS. But I
| highly doubt it. I think "some straight-forward ...
| JavaScript" is either an `import { foo } from foobar` or
| a pipe-dream in the area of "programmers always
| underestimate hours"
| scragz wrote:
| using flags for language is a bad pattern I wish would
| die. I'm not clicking on the British flag!
| jimbob45 wrote:
| What about strings + flags?
| edoceo wrote:
| String of the language, in it's language: [Flag] Suomi
| (Finnish)
| echelon wrote:
| We've gotten so far away from semantic _documents_ so we
| could build "apps".
|
| Data used to be first class. You would deliver everything
| in the HTML container and the style sheets or client
| could do whatever it wanted/needed with that data.
|
| Native search, native copy, no clever javascript tricks
| to hide or remove information from the document.
|
| The HTML data container should be immutable.
| wvenable wrote:
| > We've gotten so far away from semantic documents so we
| could build "apps".
|
| Exactly. We're still pretending that the browser is some
| kind of document display application when it's an
| application runtime. We keep adding more HTML tags and
| infinite number of CSS properties and features (that
| never get it right) when what we should have as a better
| application GUI API. Throw all the hardware acceleration
| and threading into that instead of @starting-style,
| transition-behavior: allow-discrete, interpolate-size:
| allow-keywords and ::details-content and breath some
| sanity into the platform.
|
| We've effectively re-implemented that desktop/mobile GUI
| using a bunch of cobbled together technologies and
| continue to get more esoteric and complicated every year.
| Hell, I'm not even sold on JavaScript -- it's just as
| clunky and weird as everything else.
|
| Move document rendering into high-level implementation on
| top of a better designed low-level API much like how PDF
| display in browsers is done with JavaScript.
| echelon wrote:
| It sounds like you want a game engine.
|
| I want a hypertext document viewer.
|
| > @starting-style, transition-behavior: allow-discrete,
| interpolate-size: allow-keywords and ::details-content
|
| This is sane from a declarative document styling syntax.
| wvenable wrote:
| As a developer, I want a sane platform. Sometimes I want
| to write documents and sometimes I want to write
| applications.
|
| > This is sane from a declarative document styling
| syntax.
|
| Is it? CSS intentionally avoided mixing animation with
| live layout resolution and now we have a "switch" to
| enable it. I wouldn't call that elegant.
|
| If we could just hook into layout with code this could
| have been resolved years ago instead of waiting for
| browser makers to invent yet another set keywords.
| itishappy wrote:
| I'm not particularly familiar with modern webdev, can
| anyone share a minimal example?
| bee_rider wrote:
| JavaScript encumbered pages break at least once for
| NoScript users.
| port11 wrote:
| 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.
| jakelazaroff wrote:
| When I started dabbling in web development, writing HTML
| and CSS was _already_ its own job, and professional
| JavaScript developers basically did not exist. This was
| before TypeScript, before Node, before Ajax, before React
| or even jQuery. If anything has exploded in complexity in
| the intervening years, it 's the JavaScript part of the
| equation.
|
| I agree that it's increasingly silly to ask someone to be
| an expert in all of frontend. But the primary driver of
| that is not all the new CSS features we're getting.
| tomhallett wrote:
| Agreed. Having a "HTML + CSS" engineer on the team was
| largely due to the number of hacks needed to make css
| work -- purposely adding invalid html that would only be
| parsed by specific browsers, ie5 vs ie6 vs netscape being
| wildly different (opera mobile was out of this world
| different), using sprites everywhere because additional
| images would have a noticeable lag time (especially with
| javascript hover), clearfix divs to overcome float
| issues. To be clear, I'm not saying "things were harder
| back then" or "css is simple now", but things with CSS
| were so wild and the tooling was so bad, that it what a
| unique skill of it's own that is less needed now, and the
| shift has been for people to focus on going deeper with
| js.
| computerfriend wrote:
| You can put a transition on details > summary.
| lelanthran wrote:
| > 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.
| stephenr wrote:
| > browsers don't natively support transitions between
| display: none and display: block.
|
| You say that like it's a bad thing.
| danw1979 wrote:
| Does it need animating ?
| rado wrote:
| You can't force it to be always open on desktop and collapsible
| on mobile. That was a deal breaker for me.
| sunaookami wrote:
| When you search text with ctrl+f it also searches inside
| details elements and automatically expands them!
| PhilipRoman wrote:
| Fun fact: <details> even works on github and similar sites with
| markdown-based input. You can post large inline logs in issues
| without cluttering the conversation.
| sesm wrote:
| I used this for a long time, and only now realized that I'm
| using html embedding, not some hidden markdown feature.
| chiefalchemist wrote:
| 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.
| asdfaoeu wrote:
| Why would you need aria attributes if it's summary tag?
| chiefalchemist wrote:
| I presume it has to do with AT and how it typically
| interprets the tag. TBH IDK other than I've seen it come up
| in accessibility discussions / groups.
| extra88 wrote:
| 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.
| WickyNilliams wrote:
| 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
| MrJohz wrote:
| 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 unfortunately you can't quite rely on that yet if
| you need to sink some JavaScript state to your html. But in
| general, yeah, this is a really cool feature.
| WickyNilliams wrote:
| 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!
| MrJohz wrote:
| Yeah, support was patchy until recently (and I think that
| behaviour might not even have been standardised?) so I
| think a lot of people have assumed that if you want that
| functionality you need to do something extra.
| extra88 wrote:
| Yes, Google started revealing the contents of <details> a
| few years ago, long after the element was supported in
| all browsers. Firefox added support earlier this year and
| Safari just added it.
|
| Supporting the behavior was related to changing the user
| agent CSS when they're closed and the other browsers
| implemented it and hidden=until-found at the same time.
|
| https://caniuse.com/mdn-
| html_elements_details_search_match_o...
| tapirl wrote:
| The details / summary feature can also be implemented with pure
| css without JavaScript. Here is an example:
| https://docs.go101.org/std/pkg/io.html, just click all "+"
| signs to expand contents.
|
| We can also use pure css to implement tab panels. A demo:
| http://tmd.tapirgames.com/demos.html#section-demo-4
|
| Modern css is powerful.
| xorcist wrote:
| What is a good reference to learn modern CSS? I seems most
| books and online resources are quickly outdated.
| tapirl wrote:
| I really don't know. I'm not a CSS expert. I've just picked
| up bits and pieces of CSS knowledge from Google and AI
| agents. These results often aren't perfect, so you'll need
| to make some adjustments.
| jakelazaroff wrote:
| Note that pure HTML and CSS implementations of tabs using
| <details> and <summary> 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...
| tapirl wrote:
| The pure-css effects I mentioned both don't use
| <detail>/<summary>.
| jakelazaroff wrote:
| 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 <details> / <summary> though!)
| tapirl wrote:
| for "accessible", do you mean getting focused when
| pressing TAB key?
| jakelazaroff wrote:
| Here are a few issues you'll run into with various pure
| HTML and CSS implementations:
|
| - Tabs should have an ARIA "tab" role [1], but <summary>
| doesn't accept roles.
|
| - Focusing a tab must activate the corresponding tab
| panel [2], which requires JavaScript.
|
| - Tabs should be navigable by arrow keys [3], 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://w3c.github.io/aria/#tab
|
| [3] https://www.w3.org/WAI/ARIA/apg/patterns/tabs/
| nextaccountic wrote:
| 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
| jakelazaroff wrote:
| That's actually a common strategy! It's 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.
| Permik wrote:
| This is false, recently the details element has gotten
| support for grouping them: the [name] attribute. This
| effectively enforces tab-like semantics where only one of
| the grouped details elements can be open at a time.
|
| This is a quite recent addition and the modern web is
| evolving too fast so I wouldn't put it past myself for
| missing this :)
|
| Yay for progress and for JavaScript free solutions!
| jakelazaroff wrote:
| No, the `name` doesn't affect the semantics at all. It
| introduces the (visual) behavior where opening one
| <details> element closes the others, but that's it.
|
| I posted a list of accessibility issues with any pure
| HTML and CSS implementation in another comment:
| https://news.ycombinator.com/item?id=46415271
| egeozcan wrote:
| I needed to recreate it recently because summary element does
| not allow headings inside, because it has a button role.
| only-one1701 wrote:
| Something I keep thinking about when I consider the trade-offs
| between building a site with HTML/CSS wherever possible vs JS is
| what the actual _experience_ of writing and maintaining HTML/CSS
| is vs JS. JS gets knocked around a bunch compared to "real"
| languages (although less so in recent years), but at the end of
| the day, it's a programming language. You can write a loop in it.
|
| Writing a web server in C++ is a way to get excellent
| performance. So why don't most people do it?
| breve wrote:
| > _Writing a web server in C++ is a way to get excellent
| performance. So why don 't most people do it?_
|
| Because they already wrote it in C.
|
| Apache and Nginx are both written in C. Together they run 57.7%
| of all web servers:
|
| https://w3techs.com/technologies/overview/web_server
| yurishimo wrote:
| JS got popular because some devs were trying to realize a world
| where the same code can be shared on the front and backend. I
| think on the surface, it was a noble goal with good intentions.
| Having only one programming language to handle is going to
| create some efficiency gains when you work in a large company
| with thousands of devs who all need training want to share
| knowledge as a larger organization.
|
| In the past decade, we went full JS as an industry and now
| we're starting to swing back. Server side interactivity like
| Phoenix Liveview, C# Blazor, HTMX, PHP/Laravel Livewire, Rails
| Hotwire, all of these are different abstractions around JS to
| make interoperability between the frontend and backend more
| manageable and they've come a long way to closing the gap.
| Advancements in HTML/CSS standards also deserve credit for
| closing the gap but we're still not quite there yet.
|
| But at the end of the day, the web is dynamic. As new tools and
| techniques are discovered, the industry will continue to evolve
| and certain "hacks" will become new standards and ignorant
| newcomers will reinvent the wheel again to achieve some crazy
| interactive design because they didn't know any better! And it
| wil work, mostly.
|
| Until the way we interact with browsers changes, I feel that
| we'll continue to bolt on new features over time and the web
| will continue to evolve. Just like the iPhone, a surge of use
| of smart glasses could change the computing paradigm or perhaps
| its some other device entirely.
|
| So you can (and should!) try to optimize for today, but trying
| to optimize for tomorrow will always carry the risk irrelevance
| if the market pivots quickly. Bleeding edge is risky but so is
| falling behind.
| suprjami wrote:
| Gimme a dark/light mode switch. CSS is allowed.
| johnisgood wrote:
| Checkbox and :checked are your friends.
| adzm wrote:
| Use a checkbox, d. Define vars for light mode. Override when
| checked for dark mode with body:has(#d:checked) and can include
| the dark mode media query too
| zahlman wrote:
| See https://lyra.horse/blog/2025/08/you-dont-need-js/, via
| https://news.ycombinator.com/item?id=45056878 (which discussion
| contains some deeper explanation).
| tisc wrote:
| Why would you build a switch instead of relying on the user's
| system settings? The only reason I can imagine is that your
| dark/light mode is not usable/readable so it forces the user to
| switch
| trnglina wrote:
| I often use different light/dark settings between apps and my
| system. Just because I want system UIs to be dark, for
| example, doesn't mean I want to read long pages of white-on-
| black prose on your blog.
| trinix912 wrote:
| Seconded. Just because I like to have the browser toolbar
| dark and GitHub dark doesn't mean I also want to read
| lengthy articles (LWN) in thin white text on a black
| background.
| echoangle wrote:
| Then you still don't need a switch on every website. Just
| set the browser to display the light version and have it
| ignore the system setting.
| extra88 wrote:
| That's what we need, for browsers to have a setting to
| remember our light/dark preferences per-domain.
| yurishimo wrote:
| Having it default to the users preference is nice, but you
| should still provide an override. I sometimes use my browser
| in light mode while my OS is dark mode. Many times, I find
| the contrast for dark mode websites too low unless I'm in a
| totally dark room.
| wiseowise wrote:
| Because I don't want to toggle my whole system theme based on
| one special website.
| suprjami wrote:
| My specific usage is a site to host my own internal training
| content.
|
| I want to read it in dark mode and give users that option,
| but I want to present it in light mode because dark mode
| suffers poorly from video compression when screen sharing.
|
| I currently have a JS toggle for it which uses local browser
| storage, but ditching JS would be nice if possible.
| ronbenton wrote:
| One thing I am quite hopeful for is customizable selects! It's in
| WHATWG stage 3 right now. I have seen so many horrors with
| javascript-based custom dropdowns components.
| https://developer.chrome.com/blog/a-customizable-select
| odie5533 wrote:
| The Popover API looks really cool. Could see it for tooltips or
| lightboxes.
| cantalopes wrote:
| The problem is that it's difficukt to style or animate those
| things. Unless you're builsing something for dun or technical
| where it's not important it's fine but i doubt any real world
| commercial project would be satisfied with just this
| overflowy wrote:
| 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.
| mcny wrote:
| It shouldn't have to be this way though. There is no reason
| html can't do things it needs to do to build complete apps. We
| could use reasonable defaults to allow a new type of html
| markup without JavaScript.
|
| All the http verbs. Decent html input controls What else?
| imbusy111 wrote:
| I assume you mean htmx. It doesn't have to be either/or. You
| can supplement htmx with Javascript.
|
| The core idea with htmx is that you transfer hypertext with
| controls and structure built in, not just a JSON blob that
| requires additional context to be useful.
|
| I have just shipped a very useful and interactive app
| surprisingly quickly for my customer using just htmx with a
| little Javascript.
| ksec wrote:
| I dont think anyone is arguing Google Earth should be pure
| HTML. But it is equally false you cant do Gmail with HTML only.
|
| There are things that HTML could do, and should be doing, that
| is not done or not yet possible simply due to hype and trend
| from browser vendors. We could continue to polish HTML +
| sprinkle of Javascript to its absolute maximum before hitting
| JS Apps. Right now this is far from the case.
| llmslave2 wrote:
| Gmail with html only would not be a nice experience. Modern
| gmail is really bloated but it's actually one of the few web
| apps I have no problems with.
| ksec wrote:
| Hey the email services has just proved you could offer
| better than Gmail experience with HTML + small dose of JS.
| Another example being the new FE on Github.
|
| At the end of the day it isn't really the tech that is the
| problem. Is how people use the tech. And for thousands of
| different reasons keeping it simple has always provided
| better experience evaluated on the whole.
| _heimdall wrote:
| > Another example being the new FE on Github.
|
| Github's old frontend was mostly HTML with a bit of JS,
| their new frontend is react. The old UI had its bugs, but
| it was much better than the react version in my
| experience. I still commonly find the UI out of sync with
| itself requiring a reload, but now I also frequently wait
| for the page to load and viewing large diff's is a
| performance nightmare.
| n4r9 wrote:
| Gmail used to have an html-only version if I remember
| rightly. Perhaps still does. It was faster and perfectly
| usable.
| asadotzler wrote:
| Not really. I used the HTML version for well over a decade
| and it was absolutely fine. I guess if you need fancy
| animations, maybe that doesn't suit you, but I came through
| Pine and Eudora and Gmail HTML was a million times better
| than both of those and entirely sufficient for a media that
| dates back about 50 years.
| thunderbong wrote:
| Gmail used to provide an HTML version. It got removed only
| recently
| 6510 wrote:
| Actually, I do think that. Wouldn't it be lovely to have an
| image format for truly enormous images and have the browser
| request only the chunk currently visible? It could just be a
| container format with jpg's in it. Let the file system figure
| out that x/y means tile number 56436.
|
| You could provide multiple image versions for zooming to get
| to the TB scale.
|
| Computers are really good, performance is astonishing, no
| reason why we should never be able to use a TB size image.
| Never is a really long time.
|
| Have epic panoramas, detailed scans from paintings, extremely
| easy game design and maps that just work.
| atoav wrote:
| 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.
| nchmy wrote:
| FYI, it's easy to cache the html output of a WordPress site,
| resulting in essentially a static site with graphical admin,
| page builder, and all the other bells and whistles.
| FormerlyEL wrote:
| A pleasant surprise to see Aaron's post here, we worked together
| for a bit on frontend optimization in a multi-tenant
| international ecommerce platform. That work was a large part of
| my inspiration for building https://contentblocksjs.com which
| encapsulated a lot of the JS concerns into web components.
| dpedu wrote:
| I didn't know about <datalist>, but how are you supposed to use
| it with a non-trivial amount of items in the list? I don't see
| how this can be a replacement for javascript/XHR based
| autocomplete.
| reed1234 wrote:
| > If we can hand-off any JS functionality to native HTML or
| CSS, then users can download less stuff, and the remaining JS
| can pay attention to more important tasks that HTML and CSS
| can't handle (yet).
| psnehanshu wrote:
| You can't. It's only supposed to be used for a limited list.
| lelandfe wrote:
| Don't use it, it totally blows. For another oddity to not use,
| check out the multiple select:
| https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
|
| Expecting users to press modifiers when clicking on these is so
| funny.
| Hendrikto wrote:
| > Expecting users to press modifiers when clicking on these
| is so funny.
|
| I mean... 5 year olds can figure out shift-click in
| Minecraft.
| lelandfe wrote:
| Trying to figure things out in a game is fun! Trying to
| figure things out on a website is a sign the UI sucks.
| cardamomo wrote:
| Learn it in a game, then use it on a website. It's a UI
| convention, not merely a quirk to a multi-select list.
| Kwpolska wrote:
| And even if you allow XHR and add options to a <datalist>, it
| still has terrible UX.
| JodieBenitez wrote:
| > I don't see how this can be a replacement for javascript/XHR
| based autocomplete.
|
| It can't do complex autocomplete. It's ok for simple cases
| only. I use it with a 25k long list to ease the input. Works
| well enough for this.
| econ wrote:
| I'm so not impressed by the toggle implementation... How nice it
| could have been.
|
| Nesting the elements is a truly hideous choice. The summary is
| part of the details?? I thought they were opposites.
|
| Should we also put the headings in the <p> from now on?
|
| Identifying a target should be done by id or by name. That it
| does use a name because js can't target it without makes it even
| more stupid.
|
| We already had labels for form fields. Inventing a completely
| different method for something very similar is a dumb idea. The
| old checkbox hack is more flexible and less ugly for some
| implementations.
|
| Why force the hidden content to be below or above the toggle? We
| aren't gaining anything with this.
|
| What is this nonsense for an element to not just be hidden or
| displayed but to have some weird 3rd state where only one of its
| children is shown?
|
| How should styling it even work for this new state? If I apply a
| style to the hidden content it must also apply to the link? The
| text is hidden but the style is visible??? Preposterous!
|
| Don't try style <details> to avoid unexpected behavior. Try
| wrapping the hidden content in a new element to make it behave
| normally.
|
| What is this ugly arrow? If you find 1000 websites using a toggle
| I doubt there is one using an ugly arrow like that.
|
| The default styling gives no clue about it being clickable?
|
| The pointer (awkwardly called the cursor) choice is the text
| selection?????
|
| Blue underlined "more" is what everyone does and everyone is used
| to. The cursor should be pointer. (This is css speak for "the
| pointer should be a hand")
|
| The number of js toggles you can find online where the button
| lives inside the hidden text is guaranteed to be zero. Forget
| about drop in replacement, you will have to reinvent your css.
|
| Maybe I'm dense but I also want my url to reflect the state of
| the page. I would have been impressed if that was supported.
| Personally I use actual links and disable default action in the
| listener if js is enabled/working or modify the state on the
| server if js isn't available/working.
|
| It would have been great if the toggle action was implemented as
| a simple attribute something like toggle="element name" so that
| anything can be clickable and anything can be toggleable. Have a
| "closed" as well as an "open" attribute for the target.
|
| Doesn't seem very hard. An open/closed attribute would be useful
| for other things too. Using display:none is terrible as display:
| is used for many things.
| zahlman wrote:
| > Nesting the elements is a truly hideous choice. The summary
| is part of the details?? I thought they were opposites.
|
| It gives them a semantic connection. Last I checked, HTML isn't
| really based on giving special meaning to combinations of
| sibling tags. A summary is part of the thing that conceptually
| requires detailing.
|
| > If you find 1000 websites using a toggle I doubt there is one
| using an ugly arrow like that.
|
| I think the default looks fine. But TFA clearly explains right
| there that it can be styled. (Specifically, by styling ::before
| on the summary tag.)
|
| > The default styling gives no clue about it being clickable?
|
| You asked what the arrow is, and then asked about the lack of
| indication that the summary header is clickable. The arrow is
| exactly that indication.
|
| > Maybe I'm dense but I also want my url to reflect the state
| of the page.
|
| If you scroll, should the fragment automatically update as you
| scroll past anchors? I think I'd find that quite annoying.
| econ wrote:
| Thanks for your thoughts.
|
| >It gives them a semantic connection.
|
| I understand the logic but I don't agree with it.
|
| An element should be visible or not be visible. There
| shouldn't be a 3rd state. It is a new idea and it is bad. Try
| writing a polyfill.
|
| Even if you insist it shouldn't be the only way to use it.
| There should at least be a <summary for=""> so that the
| clickable thing can be put wherever one likes.
|
| The goal is to make things convenient for the user not to
| sacrifice usability for some semantics.
|
| But if it was a summary is not semantically part of the
| details.
|
| I don't actually care about that, I just want to use it.
|
| A summary should be allowed to have hyperlinks. I
| passionately hate clickable paragraphs but if you are going
| to do that at least change the pointer into a hand.
|
| I could put the <summary> under the summary the way almost
| everyone does but then the name makes no sense.
|
| >I think the default looks fine.
|
| A summary (longer than a few words) starting with an arrow
| looks weird.
|
| The arrow would be reasonable UI for fold out menus but those
| are not summaries.
|
| I would want some margin on the left for the <details> of the
| sub menu.
|
| What I don't want is to also have padding on the parent(!)
| menu item. Seems like a very confused parent child
| relationship.
|
| >> Maybe I'm dense but I also want my url to reflect the
| state of the page.
|
| >If you scroll, should the fragment automatically update as
| you scroll past anchors? I think I'd find that quite
| annoying.
|
| Depends, if the thing is infinite scrolling and the user
| needs to send a permalink it would be nice to update it.
|
| If I have an accordion with say frequently asked questions it
| would be necessary to link to the items.
|
| It often isn't needed but I can't really picture when it
| would be annoying.
| adamzwasserman wrote:
| "I also want my url to reflect the state of the page... It
| would have been great if the toggle action was implemented as a
| simple attribute something like toggle='element name'"
|
| Your wishlist (state in attributes, URLs reflecting page state,
| anything being toggleable via simple attributes) is basically
| describing an architecture I've been working on called DATAOS
| (DOM As The Authority On State).
|
| The core idea: instead of JS owning state and syncing to DOM,
| flip it. State lives in HTML attributes. JS just listens for
| changes and reacts. Want toggle state in the URL? The DOM
| attribute is the state, so serializing to URL is trivial.
|
| It won't fix <details> being weirdly designed, but it's a
| pattern for building the kind of declarative, attribute-driven
| interactivity you're describing.
|
| Free book and open source libraries if you are curious:
| https://dataos.software/book
| anidsiam wrote:
| Your blogs have very small amount solution, but the JS use cases
| are very large. How this little replacement can do more thing? I
| usually like the idea of being using as lean as possible, if it's
| can be possible to do more thing just with HTML and CSS that's
| obviously cool. Is it really possible to replace JS with HTML in
| near future?
|
| BTW the toggle solution (expanding content) is good.
| montroser wrote:
| 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...
| kmoser wrote:
| 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 <option value="90210">Beverly Hills</option>.
| swiftcoder wrote:
| > Each <option> 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/...
| tosti wrote:
| 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?
| _heimdall wrote:
| This would be possible in XSLT, if only browsers would
| implement the latest spec rather than abandoning it all
| together.
| 6510 wrote:
| Right, I sort of expected there to be an attribute for an
| url. <datalist
| json="search.php?q=toyota+corolla">
|
| 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 a _b_ c
| kind of list length.
|
| Perhaps a wildcard would have been fun or regex options.
| <option value="* days"></option> <option value="*
| weeks"></option> <option value="* years"></option>
| singpolyma3 wrote:
| Half a million might be pushing it, but you'd be surprised
| how much you can inline without any penalty these days.
| freedomben wrote:
| 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.
| sevenseacat wrote:
| And styling! The default styling of datalists in most browsers
| is just _ugly_.
| singpolyma3 wrote:
| Open an issue with your browser or OS
| freedomben wrote:
| 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
| ilaksh wrote:
| On my android phone it just didn't show anything in the drop
| downs.
| skeptic_ai wrote:
| Try on a phone, it doesn't work. Now that's you create html
| only and no js you need to test all kind of devices to see
| quirks and try to fix it. And you'll end up with more hacks to
| fix other devices and you end up adding Js. And you'll have
| html only and html with js. With is much worse that just
| properly do it in js.
|
| I can see the op is a js hater even tho he keep saying he's
| not. Anyway doesn't matter. Just a small note.
| 65 wrote:
| It feels like some variation of this post gets submitted here
| every week.
| Y-bar wrote:
| And it will continue until node_modules shrinks!
| ozim wrote:
| That's a bit of evergreen topic. "stop bloating web with js"
| comes up fairly often and there are those people who think they
| found a solution and everyone should start using whatever they
| imagine is "best for everyone".
|
| In my opinion most of those people struggle with whatever they
| encountered in ecosystem and just want to find a way that fits
| them - while also trying to make others do the same.
|
| * _"You didn't want to make things perfect. You just hated
| things the way they are."*_
| Izkata wrote:
| Does it bother anyone else that it links to Codepen instead of
| just putting them on the page?
|
| Like I get this is a blog system but it still feels odd,
| especially for a "use this plain HTML"-style post...
| acomjean wrote:
| It doesn't really bother me.
|
| It seems to link to the authors codepen. If you us code pen you
| can bookmark the snippets. Codepen colorizes the html/css etc.
|
| Link rot is a thing though, so it's not always ideal to have
| dependencies on third party urls staying the same.
| nchmy wrote:
| Bothered me greatly. Should have done on-page AND a link to
| codepen for you to play with
| skeptic_ai wrote:
| So much about html only that makes me load 2mb of code pen and
| heavy ui to see the example. Yeah it's terrible ux. same as
| most of the examples are bad
| Sephr wrote:
| I don't see any mention of HTTP 204 or multipart/x-mixed-replace.
| Those are both very helpful for implementing rich JavaScript-free
| HTML applications with advanced interactivity.
| iammrpayments wrote:
| I was trying to rewrite some UI library with html sometime ago
| following the W3C accessibility specs and found out a lot of
| patterns can't be done with pure html and require javascript
| unfortunately.
| scrame wrote:
| like what?
| iammrpayments wrote:
| Tabs, accordion, combobox. There is a whole lot more, these
| are just the ones I can remember now.
| paulhebert wrote:
| 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!)
| rhdunn wrote:
| https://www.w3.org/WAI/ARIA/apg/patterns/ is my go to for
| accessibility requirements of components.
|
| And yes, being able to do all of these in pure HTML/CSS
| would be awesome. Though we are getting there with things
| like `details` and the newer `popover` features which
| should make things like rich tooltips, menu buttons, etc.
| a lot easier to implement. IIRC, there are also several
| anchor CSS properties to make positioning a lot simpler.
| wvenable wrote:
| > 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.
| zepolen wrote:
| All of those can be done with pure html/css, eg.
| https://codepen.io/mikestreety/pen/yVNNNm
| atomicfiredoll wrote:
| If we've concluded that's it's okay to have elements that
| change/morph, as we seem to with the introduction of things
| like details, a native tab-like element feels like a
| glaring omission. Tabs have been a long-standing UI pattern
| and forcing every site to implement their own is a
| nightmare for accessibility. (The page you're reading is
| maybe already in a browser tab.)
|
| I wouldn't be surprised if it turned out less than half of
| the custom tab interfaces on the web failed from an
| accessibility standpoint. When considering ARIA guidance, I
| don't even think it's possible to build an accessible
| version in HTML alone.
|
| Other people have recognized it's missing. Open UI has a
| draft spec for it[0] and CSS Tricks has an article from
| 2001 about Open UI's experiments with sections for tabs[1].
| I have no idea what happened on this front, though.
|
| [0] https://open-ui.org/components/tabs/
|
| [1] https://css-tricks.com/newsletter/281-tabs-and-spicy-
| drama/
| auxiliarymoose wrote:
| Accordion behavior is discussed in the article in the
| "Accordions / Expanding Content Panels" section:
|
| > Use the same name attribute on all related details (like
| radio buttons) to restrict only one open panel at a time
|
| And tabs can be a <details>-based accordion with some
| creative CSS to adjust the layout (left as an exercise for
| the reader, but I could write up an example if that would
| be helpful!)
| iammrpayments wrote:
| It won't have the necessary keyboard shortcuts.
| extra88 wrote:
| Yes, the tabs in a tabs pattern should be keyboard
| navigated using arrow keys (ironically not the Tab key).
|
| Also, the summary for the currently open details element
| will have the wrong state, 'expanded' instead of
| 'selected'. And while a set of details can now have a
| maximum of one open at a time, you can't ensure exactly
| one is always open (without JavaScript) as the tabs
| pattern requires.
| fnord77 wrote:
| <blink>
| Dwedit wrote:
| Nobody tell them about how much stuff can go into SVG. That can
| even be inlined within HTML source code.
| yurishimo wrote:
| And you can target it with css! Slap a class attribute on a
| path element; it's fine!
| troad wrote:
| Plain HTML is very cozy to me - I came of age in that era.
| Marquee tags _4eva_.
|
| But as much as I hate to admit it, it is very difficult to build
| something functional today with plain HTML and no/minimal JS. If
| you want, say, a model form that manages its children as well,
| you're basically going to end up with a 2003-era ASP-feeling
| application with way too many views and forms (as seen on your
| employer's current HR system). Or you use HTMX... and you still
| end up with just as many (partial) views, but now with so much
| implicit state that you're veering into write-only code.
|
| I dislike modern JS to the extent that I opted for Phoenix
| LiveView, just so I could achieve interactivity without ever
| having to touch JS, but in truth it's not a comprehensive
| solution. Still had to write a web worker, a bridge to handle
| things like notifications, etc. Plus the future direction of
| Phoenix, all in on AI, is worrying.
|
| Honestly, I should probably just swallow my disdain and learn to
| appreciate and use modern JS, as painful as that sounds. I want
| to write and release cool things, not get caught up in navel-
| gazing language wars.
| faitswulff wrote:
| I haven't used it in anger myself, but if you know Elixir and
| Phoenix you might like Gleam, which compiles to Javascript.
| troad wrote:
| I appreciate the helpful reply, but I think this is precisely
| the kind of indirection I need to avoid. I'm a sucker for
| elegance. If left entirely to my own devices I'd probably
| design a language / write a transpiler of my own, and wind up
| with exceedingly elegant tooling for websites, and no
| websites. :)
| llmslave2 wrote:
| This is why I don't use Typescript or frameworks in my own
| projects, I just constantly seek the cleanest abstraction
| and never get anything done. Using a deliberately messy
| solution is annoying but at least I accomplish stuff.
| wild_egg wrote:
| > Or you use HTMX... and you still end up with just as many
| (partial) views, but now with so much implicit state that
| you're veering into write-only code.
|
| You're overthinking htmx then. I do some fairly complex stuff
| with no extra partials. Trick is just always rerender and use
| hx-select and hx-target to slice out the bits you want to
| update on the current page.
|
| Server always has authoritative state and code is dead simple
| to reason about.
| troad wrote:
| > You're overthinking [noun]
|
| Yes, almost certainly!
|
| > I do some fairly complex stuff with no extra partials.
| Trick is just always rerender and use hx-select and hx-target
| to slice out the bits you want to update on the current page.
|
| Good trick! My only experience of HTMX in production entailed
| porting Stimulus code, hence the partials, but your approach
| is obviously much neater. I'll give it a shot, next time it
| might be suitable.
| bigstrat2003 wrote:
| > But as much as I hate to admit it, it is very difficult to
| build something functional today with plain HTML and no/minimal
| JS.
|
| I would certainly agree that using a little JS can get you
| further than just HTML. But I think that a plain HTML page is
| _far_ more pleasant to use (and thus, functional) than the JS
| monstrosities that dominate the Web today. There 's a _reason_
| people use the NoScript addon: because a whole lot of website
| designers use JS in ways that make the experience a ton worse
| for the user.
| llmslave2 wrote:
| It's not an either/or. Modern Javascript is actually _really_
| nice to write and use, and you can write it in a tight,
| minimal way that doesn 't bloat the page or slow it down.
| tonyedgecombe wrote:
| >you can write it in a tight, minimal way that doesn't
| bloat the page or slow it down.
|
| Yet most people don't.
|
| There are some problems with the language itself but it's
| mostly from a users perspective that I find it frustrating.
| trinix912 wrote:
| Of course you can, but most people still opt to pull in a
| whole framework (React) or heavy library (jQuery) just to
| achieve what's essentially a few XMLHttpRequests and some
| DOM changes.
| ganzsz wrote:
| Maybe because it is easier to track one library, react
| and jsx. I wouldn't use xmlhttprequest since the request
| api exist.
| zarzavat wrote:
| > There's a reason people use the NoScript addon
|
| To be snarky, do they? The average user doesn't even know
| what JS is.
|
| Users want websites that are fast and solve their problems,
| with a good UI. They don't care how it's made.
|
| Make websites that people enjoy using. A good developer can
| do that with any set of tools, though a no-JS approach is
| limited in scope.
| nashashmi wrote:
| 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 html. I think HTMz came close to
| this.
| assimpleaspossi wrote:
| 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: <marquee> 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.
| 6510 wrote:
| Sounds great <table type="text/csv" src="mydata.csv"> Then
| have it generate actual html so that you can target th's,
| tr's and td's with css.
|
| I believe the lowest hanging fruit would be <div
| src="article.html">
|
| I think formData should also be available as interactive JSON
| but perhaps it is possible to also populate a form with
| fields from a json with something like:
| <form src="mydata.json"> <table> <input
| name="baz" type="number"> </table> </form>
|
| Where mydata.json is: {"foo" : "bar", "baz"
| : "42"}
|
| And have something like this come out:
| <form><table> <tr> <td><label
| for="foo">foo</label></td> <td><input type="text"
| name="foo" value="bar"></td> </tr> <tr>
| <td><label for="baz">baz</label></td> <td><input
| type="number" name="baz" value="42"></td> </tr>
| </table> </form>
|
| It wouldn't cover everything but it is very nice not to have
| the later if you don't really need it.
| moritzwarhier wrote:
| > 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.
|
| Are you sure you are talking about the functionality of the
| marquee tag? What exactly do you mean by "implement
| horizontal scrolling often used on shopping websites. Now it
| uses JS to achieve the same"?
|
| For a banner-type text "Sale: 50% off until New Year" I can
| imagine this. And this is possible with almost no JS, by
| using a CSS animation on translateX. I think you need to pass
| the initial width of the content one time from JS to CSS via
| a custom property IIRC, and update that variable on resize,
| for example using a ResizeObserver, to avoid a jump when
| reaching the "wrap around"...
|
| But - sorry if this a misunderstanding - I have a sneaking
| feeling that you might also have things in mind like swipable
| horizontal lists etc?
|
| This is also possible using CSS _in theory_ (scroll-snap and
| overflow-auto, and CSS to hide the scrollbars). But last I
| tried to use it, it simply wasn 't good enough to sell it,
| compared to a fat JS library that did the trick, perfectly,
| on mobile and desktop.
|
| When it comes to UX niceties, I feel it's pretty common to
| have HTML+CSS solutions that are good enough in theory, but
| suck in practise.
|
| For the horizontal scrolling with "snap", I would also like a
| good JS-free solution. But I feel that the more interactive
| and complex the UX patterns become, it would be senseless
| bloat to build a specific implementation into the platform.
|
| I think that "autocomplete" inputs are a good example for
| this, as discussed in another thread.
|
| I once tried to implement a custom autocomplete using
| datalist (including dynamically updating the list with xhrs).
| In the end, the native element had so many issues that it was
| a waste of time and a JS solution was way better. At the
| time, that JS solution was Alpine.Js, because it was a b2b
| app with minimal a11y requirements and JS-allergic
| developers.
|
| Within an hour, I was polishing keyboard use while the "near-
| native" solution using datalist was broken in a thousand
| different ways in every browser and in the end didn't work
| well at all.
| abustamam wrote:
| I miss marquee... I burned more tokens than I'd like to admit
| to build a marquee-like feature in react and it was really just
| the same text twice with an animation that hopefully no one
| notices isn't a clean loop on some viewport sizes (since it
| restarts after reaching the end).
| avodonosov wrote:
| I am reading the CodePen example for summary/details. Especially
| the CSS part.
|
| Its so easy, like a breeze!
| hn111 wrote:
| I've tried replacing my modal components with the <dialog>
| element, but had to reverse everything due to this issue:
| https://github.com/whatwg/html/issues/9936
|
| In short: you can't have an interactive popover (e.g. a toast
| notification) on top of a dialog modal.
|
| I'd love to use the new native elements but we're sadly not quite
| there yet.
| shahzaibmushtaq wrote:
| This is helpful when development revolves around static
| environment.
| busymom0 wrote:
| I really try not using JavaScript unless absolutely needed. On my
| latest project, the whole site actually functions without
| JavaScript and is server side rendered. However, there's some
| small piece which I really needed JavaScript for couple reasons.
|
| Basically, I have a site which collects the top STEAMD posts from
| places like HN, lobsters, tildes, slashdot, bear, reddit etc and
| displays them in chronological order. I wanted a way for users to
| block posts with certain keywords or from specific domains. I
| didn't want to do this server side for both performance reasons
| plus privacy reasons. I didn't want users to need signing up or
| something to block. I also didn't want to collect block lists for
| privacy reasons. So, I resorted to using JavaScript and local
| storage. All posts within the filter for the date are sent and
| JavaScript is used to block posts with keywords before
| displaying. So my server never knows what keywords are blocked.
|
| Site for anyone curious:
|
| https://limereader.com/
| backtogeek wrote:
| Brilliant I will be adopting a few of these, I have been on a
| personal quest to reduce js use recently, I feel like I spend
| more time debugging js than producing the end result.
| Theoleff wrote:
| 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/
| danieloj wrote:
| 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
| Theoleff wrote:
| 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.
| freedomben wrote:
| 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) :-)
| Theoleff wrote:
| Thanks for sharing that! It's a super common story.
| Frontend patterns moved fast (especially for the last 3
| years), and not always in a way that encouraged checking
| what the browser itself could already do.
|
| If you want to improve a bit and discover more what CSS
| and HTML can do today, I also try to post daily on my
| LinkedIn: https://www.linkedin.com/in/theosoti/
| shimman wrote:
| 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.
| kitd wrote:
| Indeed the "Learn X" books may even have a vested interest in
| not revealing rarely used features, so that you learn to
| reimplement them in X.
| Theoleff wrote:
| Thank you, it means a lot!
|
| I originally started writing it because I was tired of books
| becoming obsolete every two years while the underlying
| problems stayed the same.
| levmiseri wrote:
| A missed opportunity to not have all of these examples inline.
| The page/blog-post would be so much more convincing if it
| utilized all of these HTML replacements instead (or in addition)
| to linking to codepen.
| dvh wrote:
| Absolutely mind boggling. I've seen it many times before.
| There's some FooMaker v1.0 announced and you click on it
| thinking it will allow to easily make Foo and the example is
| how to disable FooMaker's lights l while AC is running or some
| other obscure edge case that affects like one in a million
| people, no examples how to actually use it for most common use
| case or how the result look like.
| itishappy wrote:
| I had assumed this was a 25 year old article at first glance.
| Those dithered gifs sure are a throwback!
| nfrmatk wrote:
| I was also frustrated to find the examples weren't inline, but
| I think this is a guest blog post which makes it a bit more
| understandable.
| hollowturtle wrote:
| I don't want to be so negative, but we got details and popover
| after literally decades, and we still have datalist presented as
| a plausible option? Html is so underdeveloped and the first we
| all agree on that the first we'll pretend from committee real
| advancement
| 6510 wrote:
| The committee is an unsolved puzzle as old as mankind. That's
| not to discourage you. If you do solve it it would remedy
| almost all of our problems. If the solution could be found
| instantly in 5 seconds someone would have solved it already.
| This one is going to take some actual thinking and modeling.
| hollowturtle wrote:
| I know for sure that Apple, who has an important seat on the
| standard committee, holded back innovation for so long, it's
| not a matter of finding or not finding solutions. They're
| failing us for different interests
| 6510 wrote:
| They are the new Microsoft, if the web died it would be
| good for them. We've also tried to have elected bureaucrats
| make the decisions. Systems giving everyone one vote also
| turned out terrible as expertise and thoughtfulness drowns
| in superficial noise. It is kind of embarrassing how well
| the dictator model works. Personally I prefer to do
| everything alone. There are no meetings, barely any
| paperwork, I get to own the bad choices. So far I get along
| well with my past self and my future self. I do consider it
| a temporary hack until figuring things out in groups is
| solved. Robot overlords sounds increasingly appealing.
| alwillis wrote:
| > I know for sure that Apple, who has an important seat on
| the standard committee, holded back innovation for so long,
| it's not a matter of finding or not finding solutions.
| They're failing us for different interests
|
| Apple isn't the problem.
|
| Apple was the first to ship :has(), which developers wanted
| for 20 years but was thought to be essentially impossible
| to implement [1].
|
| Apple pushed to get consensus on how to implement masonry
| layouts in CSS [2].
|
| And they were first to ship the new specification in a
| browser you can use right now [3].
|
| This dashboard shows Apple slightly ahead in terms of new
| CSS features being implemented and interoperable with
| Firefox and Chrome [4].
|
| [1]: https://webkit.org/blog/13096/css-has-pseudo-class/
|
| [2]: https://webkit.org/blog/16026/css-masonry-syntax/
|
| [3]: https://webkit.org/blog/17660/introducing-css-grid-
| lanes/
|
| [4]: https://wpt.fyi/interop-2025?stable
| vijaybritto wrote:
| What would make this super easy to adopt?
|
| A simple page which shows what native components are available
| with/without the need for polyfills for a given browserslist
| config
| thayne wrote:
| It seems like an oversight that there isn't a native way for a
| popover to be activated by hovering over the target element.
| Cort3z wrote:
| I love semantic html. It feels so much more modern and efficient
| than all of these fashion-driven front end tools.
| bodash wrote:
| 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 the interviewer raise an eyebrow. In later
| stage, even I that passed the exercises, still didn't get the
| job.
| oceansky wrote:
| Having a separate css file make small components so much
| cleaner. I am not against tailwind, but I wouldn't want to use
| it in front-end interviews.
| rokkamokka wrote:
| 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.
| christophilus wrote:
| 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.
| abustamam wrote:
| In every React team I've been part of we've wanted to use as
| little react as possible and use native DOM apis when
| possible. React would be used purely for state management or
| interactivity.
|
| I feel like teams that have used react enough learn that the
| less React you can use the better :) it's a great tool, but
| most teams use it because it's all they know and they don't
| know what they don't know about html.
| shimman wrote:
| Weird comment, I'm a web dev that has been using react for
| 10+ years and I prefer using native browser features whenever
| possible. I'd honestly avoid hiring framework specific devs
| because the skills required are never about just one single
| framework.
|
| Also this is just all JS + HTML here, let's not act like it's
| impossible to learn the most popular frontend tool at the
| moment.
| halfmatthalfcat wrote:
| Because nobody outside of the HN-sphere cares about HTML
| purism, nor should they.
| jspdown wrote:
| It's not HTML purism. It's simply recognizing that HTML and
| CSS have evolved a lot and many things don't need (or are
| close to not need) JS anymore. This shouldn't be taken as an
| anti-JS article, everyone benefits from these gradial
| improvements. Especially our users who can now get a uniform
| experience.
| augustk wrote:
| Progressive enhancement is the way to go if you care about
| technical excellence. For some reason it fell out of fashion.
|
| https://en.wikipedia.org/wiki/Progressive_enhancement
| _heimdall wrote:
| It fell out of fashion because the entire web was consumed by
| react.
| petepete wrote:
| > if you care about technical excellence
|
| Or accessibility.
| herpdyderp wrote:
| Before anyone wastes a lot of time like I did trying to use the
| popover API: it is not ready yet. You can do very basic things in
| all browsers but positioning is still different and/or totally
| broken per browser.
| senfiaj wrote:
| Yes, HTML & CSS alone won't replace JS. Of course, for
| complicated form validation HTML is not sufficient. But IMHO
| it's very important to provide basic functionality in HTML /
| CSS as much as possible / reasonable. Moving the functionality
| to HTML / CSS can potentially improve the SEO.
|
| As for positioning, there is an experimental feature @position-
| try. Here I made a small demo where it handles overflows.
|
| https://waspdev.com/articles/2025-06-29/css-features-web-dev...
|
| But yeah, that's kind of limited if you need nice animations or
| some other complicated thing. Although it's fun.
| extra88 wrote:
| Yes, popover's uses are limited without CSS anchor positioning
| but it will be supported in all major browsers very soon.
|
| In the meantime, there is a polyfill to load in browsers
| without support.
|
| https://caniuse.com/css-anchor-positioning
| Devasta wrote:
| JavaScript is the primary language of the web, HTML is just the
| payload carrier.
|
| I don't want it to be this way, but HTML has nothing approaching
| even one tenth the ambition of XSLT and XForms.
|
| If HTML were proposed today, you would be laughed out of the
| room.
| nasso_dev wrote:
| 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
| zaidf wrote:
| The problem is that CSS continues to be a pain in the ass, even
| as it evolves. There is no other reason why something like
| tailwind should have the traction it has.
| edwardtay wrote:
| The <details> and <summary> elements are great, but I think the
| bigger missed opportunity is the lack of inline examples/demos on
| the page itself. Would be much more powerful to actually show
| these working rather than linking to external codepens.
|
| A few thoughts on the practicality:
|
| 1. Progressive enhancement is the real win here, not "replacing"
| JavaScript. These HTML features provide a baseline that works
| without JS, then you enhance with JS for better UX (animations,
| state persistence, etc.)
|
| 2. The details/summary approach breaks down when you need: -
| Custom animations/transitions - State synchronization across
| multiple elements - Analytics tracking on user interactions -
| Keyboard shortcuts beyond basic tab navigation
|
| 3. What about the <dialog> element? That's another underutilized
| HTML feature that could replace a ton of modal/popup JavaScript.
|
| 4. Have you explored the Popover API? It's getting broader
| browser support and handles a lot of common UI patterns without
| JS.
|
| The spirit of "use the platform" is great, but the title feels a
| bit clickbaity - you're not really replacing JS, just avoiding it
| where unnecessary. Which is good practice anyway!
| conception wrote:
| 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.
| peesem wrote:
| why are people so obsessed with restricting details/accordion
| elements to only one open at a time? let me open what I want to
| zenmac wrote:
| One good thing about NOT having JS is what the page can function
| in Tor Browser's "Safest" mode!
|
| A step down is to have JS only on your domain. "Safer" mode.
|
| Try to avoid web site that require "Standard" to view and run
| properly.
| cess11 wrote:
| In my mind "Just HTML" does not include CSS.
| hinkley wrote:
| I was stuck on the backend while CSS3 absorbed most of the
| functionality of Less and Sass and now I'm trying to play
| catchup. If there had just been a CSS4 I'd be able to find a
| tutorial to teach me everything I missed in the interim.
___________________________________________________________________
(page generated 2025-12-28 23:00 UTC)