- cross-posted to:
- html@programming.dev
- cross-posted to:
- html@programming.dev
You must log in or # to comment.
I’m confused. This is exactly what https://htmx.org/attributes/hx-target/ is for since they’re already using htmx. This doesn’t make sense to add to the html spec unless ajax requests themselves are added such that browsers will do this automatically. Which I don’t think anyone wants.
I think the point is that they don’t want to have to use a full JS framework (which is what HTMX is) for this behavior.
And this is where HTMX fits in. It’s an elegant and powerful solution to the front-end/back-end split, allowing more of the control logic to operate on the back-end while dynamically loading HTML into their respective places on the front-end.
But for a tech-luddite like me, this was still a bit too much. All I really want to do is swap page fragments using something like AJAX while sticking to semantically correct HTML.
EDIT: Put another way, if you look at HTMX’s "motivation"s:
motivation
- Why should only
](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/a) & [be able to make HTTP requests? - Why should only
click&submitevents trigger them? - Why should only
GET&POSTmethods be available? - Why should you only be able to replace the entire screen?
By removing these constraints, htmx completes HTML as a hypertext
It seems the author only cares about the final bullet, and thinks the first three are reasonable/acceptable limitations.
I see, I guess I get the point they’re making. We can do iframe reloads based on clicks without javascript, why not div reloads. I think framing it as a way of doing this without javascript rather than without a framework would be clearer and a better argument
So here’s what I propose (and what I’ve built as a small demo below):
They’re suggesting it should be part of browser behaviour. They couldn’t demonstrate it without JS.
Yeah, I missed the part where they wanted it to be built into the browser
- Why should only
