-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rework "find" extended CSS selector #1597
Comments
Calling BTW: renaming Edit: I was wrong, |
Considering the following situation: <div hx-trigger="input from:find input">
<div>Something</div>
<input type="text">
<input type="text">
</div> With the current With your PR though:
<div hx-trigger="input from:find input:first-child">
<div>Something</div>
<input type="text">
<input type="text">
</div> Using So I'm afraid it wouldn't fix the issue here I agree with you that |
Meh, you're absolutely right. I don't know why I thought it would return the first element. So let's first discuss what approach we want to take here before I adjust the related PR to it. What if we used a function-like syntax similar to CSS pseudo-classes
<div hx-trigger="input from:first-child(input[type="submit"])"></div> |
I like those ideas
|
I agree.
The function syntax feels more natural to me and encloses the selector, as is done in CSS with :has(), etc. But yes, it's a matter of taste. Without we have to rename <div hx-trigger="input from:first-child(input[type="submit"])"></div> vs. <div hx-trigger="input from:first-child input[type="submit"]"></div>
Don't worry, the documentation will clarify this 😜 |
Either rename next/previous as you said, but we could also
|
When using multiple keywords a one-time legacy name info could be helpful, shown in the console. |
I've been looking for a |
I must admit I'm not very satisfied with the current
find
keywordclosest
seems obvious because it's going to retrieve the closeST element, so obviously only one.But when it comes to
find
, maybe is it because I'm not a native English speaker, but I "feel" it differently depending on the contextfrom
keyword, andhx-include
, I would expect it to return all elements matching the selector (which is not correct, current implementation only returns the first matching child)Examples for that second point:
Here, I would instinctively expect the div to listen for
keyup
on both inputs, or more if there were more of them.Not only does it only retrieve the first matching child, the only way to accomplish such behaviour as of today would be using a standard CSS selector such as
#result input[type='search']
, which requires adding an ID / class to be able to select on that parent div specifically.I find it confusing because the word
find
itself doesn't indicate if it's going to be one, or many elementsSo, would it make sense to add a new keyword to make that clearer ? Which would btw add the feature of listening on multiple elements using
from
as mentioned aboveExamples that come to mind:
find-first
andfind-all
find-child
andfind-children
closest-child
andchildren
Feel free to suggest other ideas, especially given that my English isn't that great
For retro-compatibility, I would then suggest to keep
find
being an alias of whatever new keyword that would replace it, but deprecate it / undocument itLet me know
The text was updated successfully, but these errors were encountered: