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

Replacing JavaScript with Just HTML

htmhell.dev

Post reply on HN
Print view View original

251–260 of 296 posts

Re: Replacing JavaScript with Just HTML

#251

Post by suprjami »

tisc wrote: post #87
suprjami wrote: post #13

Gimme a dark/light mode switch. CSS is allowed.

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

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.

Re: Replacing JavaScript with Just HTML

#252

Post by Permik »

jakelazaroff wrote: post #192
tapirl wrote: post #186

Earlier quoted context omitted.

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.

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

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!

Re: Replacing JavaScript with Just HTML

#253

Post by wvenable »

echelon wrote: post #196
wvenable wrote: post #101

Earlier quoted context omitted.

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

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.

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

Re: Replacing JavaScript with Just HTML

#254

Post by Theoleff »

freedomben wrote: post #224
Theoleff wrote: post #139

Earlier quoted context omitted.

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

That exactly describes me. I'm not a good frontend person. I got really, really good at building desktop GUIs in Swing (Java) back in the day and really imprinted on that way of doing things. When moving to web, I found the the display landscape really challenging to grok. I read a few books and got to where I could get most of what I wanted done, but it always took me way longer than it felt like it should, and cert…

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/

Re: Replacing JavaScript with Just HTML

#255

Post by Theoleff »

shimman wrote: post #230
Theoleff wrote: post #109

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

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

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.

Re: Replacing JavaScript with Just HTML

#256

Post by echelon »

wvenable wrote: post #253
echelon wrote: post #196

Earlier quoted context omitted.

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.

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

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.

Re: Replacing JavaScript with Just HTML

#257

Post by wvenable »

echelon wrote: post #256
wvenable wrote: post #253

Earlier quoted context omitted.

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

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.

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.

Re: Replacing JavaScript with Just HTML

#258

Post by nfrmatk »

levmiseri wrote: post #111

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.

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.

Re: Replacing JavaScript with Just HTML

#259

Post by extra88 »

iammrpayments wrote: post #127
auxiliarymoose wrote: post #104

Earlier quoted context omitted.

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

It won’t have the necessary keyboard shortcuts.

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.

Re: Replacing JavaScript with Just HTML

#260

Post by jakelazaroff »

Permik wrote: post #252
jakelazaroff wrote: post #192

Earlier quoted context omitted.

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

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!

No, it's still true. I'm aware of that hack, but unfortunately it doesn't solve the problems with pure HTML and CSS tabs.

Crucially, the `name` attribute does not semantically turn a group of elements into a set of tabs. All it does is introduce the (visual) behavior where opening one element closes the others.

I posted a list of accessibility issues with the hack in another comment: https://news.ycombinator.com/item?id=46415271

Post reply on HN