maybe I need to add a property to key events indicating this condition to make it easy to test for

name suggestions (or alternative approaches) welcome

So it seems that by default the new 1.3.2 release scrolls to the element that's being replaced on ajax calls. e.g.

<form action="/url" data-hx-swap="outerHTML" data-hx-target="#target" method="post" >

Will scroll to #target. The previous version swapped the element while keeping the view position which was my desired behaviour. What are my options?

🤔

This should have only been for boosted links, IIRC

give me a a bit and I'll figure it out

Hmmm. Yes, I think I explicitly only scrolled to top if 1) the link was boosted 2) you haven't specified anything else.

I don't think my commit did anything with scrolling to the element. I added a "show top" if it was a boosted link to mimick the behavior of normal navigation

To confuse matters the form actually is boosted. I use the hx-boost on the to boost everything by default. The regular links work better for navigation now as they scroll to the top of the page as a user would expect. The form submission definitely scrolls to the hx-target though I wonder if it's because I'm not using a hx-post. I'll look into that now.

Not having an explicit hx-post attached to the form tag was the issue. The reason it wasn't on previously is because I'm trying to use htmx to enhance a regular server side elixir app and make it work 100% without javascript too. It actually did work in the last version but maybe I was using it wrong and adding the extra hx-post tag to a form is only a minor annoyance with the duplication.

OK, let's do a bit more research on this

I'll check if forms scroll to top on submission, that's a debatable situation (vs links)

That would probably depend on the situation. If you already have a site that you add boost to, scrolling to top on submit would probably be what you expect. But if you add a form with the intention of it being submitted via Ajax then it would depend I guess

Perhaps skip the scrolling if you specify a target on the form / link?

I'm personally happy with scrolling to top on tags whether you specify a href link or not as that's the expected and probably most common behaviour. For forms I feel different because some are for actions on the same page (e.g. add to cart - don't scroll) and some are submit then redirect (e.g. add new blog post - should scroll). Maybe if there were a simpler way of setting scroll behaviour other than scroll:top and scroll:bottom on hx-swap. If we are now scrolling to top by default there at least needs to be a scroll:ignore to keep the current position because there's now no current easy way to do that for links.

GitHub issue plz

Built a comparison site for different HTML over the wire solutions https://html-over-the-wire.herokuapp.com/ Planning to boost with htmx and other upgrades, any comments / feedback appreciated 🙏

I generally think tables are easier of they are long instead of wide, so in this case i would have inverted the axis, this would also make the distance between each checkbox consistent.

in most cases green is good except for compilation, where it is inverted, id probably have called it 'usage without compilation'

its also a little hard on the eyes if you are red/green colorblind, so id make the boxes a little more pronounced, possibly a slightly lighter color of green.

(sorry but you asked for critique) .. these are just things id keep in mind when making something like this in the future, not saying you need to change anything here! 🙂

ah i see the compare table is nice 🙂

unbelievable, thank you for putting the time in for this!

for sockpuppet, you don't need a compilation step for the javascript. if you use it as it comes, without adding js enhancements, you can do it with the premade javascript that comes with the library. (So it's basically the same as using the CDN.)

also i have to challenge your entire concept of 'extendable'

Noted 👍

I accept your challenge 😉

Like what is your definition of extendable here? Cause all of these libraries are extendable as far as I can tell.

I like to think more along the lines of how htmx and unpoly let you to create your own extensions or plugins. But I have certain reservations about how the other frameworks let you do it or how far you can customise or build new behaviours with them. One for the fact that they are tightly coupled with an existing framework or so like how Hotwire and RAILS or LiveView and Phoenix and so on.

The coupling of extension to implementation is implicit in the entire thing. I don't know that the way you're thinking about it is a valid comparison between these things.