Add config option to disable scroll into view for targets of boosted links and forms

[xhaggi]

This adds a configuration option to enable/disable scrolling up after swapping a boosted link or form.

Related discussion #407

@David-Guillot you have requested something like that in #407 (comment)

[Telroshan]

Hey it's me, the annoying semantic guy
I'm just wondering if boostedShowTop is the right choice of name here ; I know the swap spec uses the keyword "show" internally, but the user never gets to see that. I don't find that name super intuitive at the first glance to guess what it's doing.
Why not use the term scroll instead of show here, such as boostedScrollTop ?

Though looking at the existing config, maybe a name such as scrollBoostedTop or scrollBoostedElementsTop would be more consistent? (as we have refreshOnHistoryMiss, includeIndicatorStyles, allowEval for example, where the verb is the first word of the config property)
I'm suggesting this one here because swapSpec["show"] = "top" resolves to a scrollIntoView call

Let me know your thoughts on this

[sjc5]

I would love to see this get merged! One great thing about hx-boost is that you can, if you choose, basically just always target the full document, and get what you might call an "automatic" SPA user experience on top of a totally traditional MPA developer experience. Although not totally in line with HTMX's primary use case of using smaller, granular html snippets, I think this is also a really valid use case for a lot of sites. This is what we're doing by default with Hwy, for example. Unfortunately, the default scroll-to-top behavior makes some form interactions a little goofy, and not being able to turn that off is odd.

At risk of overthinking and delaying merging, I'd love to see this take options:

scrollTopAfterBoosted: true | false | "anchor-only" | "form-only"

[xhaggi]

I don't have a strong opinion on the name I've chosen, so I'll adapt it to your suggestion. Will do it tomorrow.

[Telroshan]

And I'm not a native speaker so let me invoke @alexpetros or @1cg as my choices of naming have already proven not to be the best ones in the past 😆

[1cg]

should we allow for more than just a global override, or is global good enough? (Thank you for your work on this @xhaggi )

[sjc5]

should we allow for more than just a global override, or is global good enough? (Thank you for your work on this @xhaggi )

I think global override is a good start. But yes, I think it would be great to also be able to override on a per-form / per-anchor basis. The main use case for me, just for the sake of being explicit, is to be able to return form validation results in what might be a long form, without scroll state being lost.

[alexpetros]

I think we should use scrollIntoView, because that aligns with the JS name. I also don't know why we would limit this to boosted links. I'd suggest that we do htmx.scrollIntoView which by default scrolls the non-OOB element into view on all swaps.

We also probably will want a granular way to enable/disable that (and add it to OOB swaps), but that's no reason to hold up the global config.

[sjc5]

I think we should use scrollIntoView, because that aligns with the JS name. I also don't know why we would limit this to boosted links. I'd suggest that we do htmx.scrollIntoView which by default scrolls the non-OOB element into view on all swaps.

We also probably will want a granular way to enable/disable that (and add it to OOB swaps), but that's no reason to hold up the global config.

Based on some background discussions I read earlier (sorry don't have the links handy), the limitation to boosted forms and anchors is to mimic default browser behavior (though the default smooth scroll violates this). Personally I just want a way to set it to no scrolling at all, to avoid the UI slingshotting effect when you submit a form (but still be able to do simple progressive enhancement), so other than that have no strong opinion :)

[alexpetros]

I would love to see this get merged! One great thing about hx-boost is that you can, if you choose, basically just always target the full document, and get what you might call an "automatic" SPA user experience on top of a totally traditional MPA developer experience

Unrelated, but isn't this just a regular link?

[sjc5]

I would love to see this get merged! One great thing about hx-boost is that you can, if you choose, basically just always target the full document, and get what you might call an "automatic" SPA user experience on top of a totally traditional MPA developer experience

Unrelated, but isn't this just a regular link?

Yep, regular anchor tag with hx-boost on for automatic client routing. Astro just recently released their client routing solution to get this same effect.

[1cg]

ok, so https://htmx.org/attributes/hx-swap/ is where you can specify scrolling behavior

by default it does nothing, unless we are taking about a boosted link or form, so this global really only applies to those and the name should probably reflect that

you can override the behavior of a boosted form w/ something like this:

<body hx-boost="true">
  ...
  <form hx-swap="innerHTML scroll:none" ... />
    ...
  </form>
  ...
</body>

(not tested)

[sjc5]

ok, so https://htmx.org/attributes/hx-swap/ is where you can specify scrolling behavior

by default it does nothing, unless we are taking about a boosted link or form, so this global really only applies to those and the name should probably reflect that

you can override the behavior of a boosted form w/ something like this:

<body hx-boost="true">
  ...
  <form hx-swap="innerHTML scroll:none" ... />
    ...
  </form>
  ...
</body>

(not tested)

Unless I'm missing something, I think it's really important to inherit the global hx-swap setting. Sometimes that's going to be more complex, refer to extensions, etc.

If you've set hx-boost at a parent level, you can just use traditional form attributes.

<form method="POST" action="/whatever" scrollTopOnResponse="false">

Having to repeat something like "morph:innerHTML" everywhere isn't really necessary

[1cg]

You can just modify the scrolling behavior:

<form hx-swap="scroll:none" ... />

I'm not saying we don't need this global config, I'm just thinking out loud about how widely it matters with respect to the name.

Maybe htmx.config.scrollTopIntoViewOnBoost?

[alexpetros]

by default it does nothing, unless we are taking about a boosted link or form, so this global really only applies to those and the name should probably reflect that

I understand now, and agree—forgot that boost has special scrolling behavior. I think htmx.config.scrollTopIntoViewOnBoost is also the right name.

[sjc5]

You can just modify the scrolling behavior:

<form hx-swap="scroll:none" ... />

I'm not saying we don't need this global config, I'm just thinking out loud about how widely it matters with respect to the name.

Maybe htmx.config.scrollTopIntoViewOnBoost?

There may be a bug because I've never been able to get that syntax to work. It still scrolls to top for me on a boosted form, with hx-boost set on the body.

[1cg]

OK, that's a bug for sure. Do you mind debugging it? The "scroll" should be determined by the swap spec. Cheers, Carson /// big sky software ///

…

On Thursday, November 2nd, 2023 at 1:19 PM, Sam Cook ***@***.***> wrote: > You can just modify the scrolling behavior: > > <form hx-swap="scroll:none" ... /> > > I'm not saying we don't need this global config, I'm just thinking out loud about how widely it matters with respect to the name. > > Maybe htmx.config.scrollTopIntoViewOnBoost? There may be a bug because I've never been able to get that syntax to work. It still scrolls to top for me on a boosted form, with hx-boost set on the body. — Reply to this email directly, [view it on GitHub](#1459 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AADSRP3NOXKUHAK4SMZRWHDYCPW5TAVCNFSM6AAAAAAYQCMK2KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOJRGQYDSNRYGM). You are receiving this because you were mentioned.Message ID: ***@***.***>

[sjc5]

OK, that's a bug for sure. Do you mind debugging it?

Yep, happy to. Thanks for hanging in there with me :)

[alexpetros]

@sjc5 would you mind moving that investigation to a new issue?

@xhaggi are you available to change this to scrollIntoViewOnBoost?

[xhaggi]

First of all, scroll and show do different things when used as modifiers in hx-swap. show calls element.scrollIntoView and scroll calls element.scrollTop. For a boosted link or form, the swap modifier show is set to top by default.

You can just modify the scrolling behavior:
<form hx-swap="scroll:none" ... />

@1cg to change the default behavior, you have to use hx-swap="show:none" on boosted links and forms.

@alexpetros I don't really like scrollTopIntoViewOnBoost or scrollIntoViewOnBoost because neither explain what is really happening. What is being scrolled into the view? I like scrollTopOnBoost more.

[xhaggi]

I have now decided to use scrollTopOnBoost and also added a note in the hx-swap documentation on how to disable the default behavior on a per-element basis

[alexpetros]

@alexpetros I don't really like scrollTopIntoViewOnBoost or scrollIntoViewOnBoost because neither explain what is really happening. What is being scrolled into the view? I like scrollTopOnBoost more.

The reason to use scrollIntoViewOnBoost is that it mirrors the DOM API, which makes it easier to search the documentation for. If I'm like "can htmx do scrollIntoView that I read about on MDN," this makes it easier to find. I don't feel especially strongly about it vs scrollTopOnBoost, which is fine, but I do prefer scrollIntoViewOnBoost for this reason.

@1cg we just need a final decision on scrollTopOnBoost or scrollIntoViewOnBoost (or whatever you want the config to be called).

[xhaggi]

@alexpetros after a second thought the name scrollIntoViewOnBoost makes more sense, especially if you use hx-target on a boosted element. This will cause the target to scroll into the viewport. Without hx-target the body is used and it will scroll into the viewport, causing the page to scroll to the top. However, I think that probably very few users are aware of this. We should definitely make this clear in the documentation.

[xhaggi]

Force pushed. @alexpetros let me know if the documentation is clear enough.

[alexpetros]

@1cg beat me to punch and merged it, but the documentation is great :)