htmx

ya but you might need to extend to check also on textfield and maybe even anything with contentEditable 🙂

alternatively you could catch for these use cases in javascript 😦 or hyperscript 🙂 and dispatch a custom event

I mean, that css selector can be as ugly as we like

but you eventually hit a point where the event is its own thing

ya i think the cleanest solution is to invoke some plain ol' js

the logic, which sounds moderately non-trivial, has to live somewhere

js, say what one will, does allow you to express logic

but I still argue that this should be exposed as a config option with a default of disable keybind when focused on input, it seems like a gotcha for every user otherwise.

though I guess it does feela bit like a 'bloaty' feature.

i'm trying to think if there is a better way to deal w/ this

I don't want to get into the business of fixing up javascript events

and my first gut reaction is "use hyperscript"

which is the pressure release for stuff like this

but also, using hyperscript is insane, so a bit of an impasse

would be nice if there were a way to hook into the event production cycle so you could add a property to the mouse event

that basically made this into a property that could be easily checked in an htmx event filter

OK, this isn't documented, but you *could* do it like this:

```html
<button 
  hx-trigger="click, keyup[isANavEvent(event, 'D')] from:body"
        hx-post="/doit">
  Do It! (alt-shift-D)
</button>
```

where `isANavEvent` does all the ugly checking that you want

the `event` symbol is available in filter condition, and that isn't changing

https://mekhami.github.io/

I started a blog just to blog about my experiences with htmx lol. It's just part 1 right now which is 90% rant and 10% walkthrough, but it's there anyway.

I think another example of <@!230731315815776256>'s problem can be seen on the htmx homepage itself.  Particularly any of the examples pages that involve editing, like https://htmx.org/examples/inline-validation/.  A forward-slash isn't valid input for an email but we should be able to accept and validate it.  It also shouldn't result in the jarring experience of the focus shifting to the "Search Docs" input while focus is on a form field.