Filter the list of commands with a search term entered by the user.
Implemented using custom elements, filtering the elements directly.
Short screencast showing how it works attached.
Filter the list of commands with a search term entered by the user.
Implemented using custom elements, filtering the elements directly.
Short screencast showing how it works attached.
Nice work! Can you make a couple of changes?
@ -32,3 +24,1 @@
</li>
{{ end }}
</ul>
<filtered-list filter-field="#filter-commands">
I admit I haven't kept up with web stuff in a while. What's going on here? How broadly compatible is your approach with various web browsers?
In the JavaScript code, I define a custom element. That‘s basically a way to invent new HTML tags. They must contain a - in the name which makes them forward-compatible as standard elements are not allowed to contain a -. They are supported by 96% of installed browsers world-wide. If you prefer, I can hide the filter bar if the browser doesn‘t support them, or the JS did not load for some reason. The custom elements themselves do no harm, as browsers do treat unknown elements basically as spans.
The JS code runs for every time the element is defined. You can imagine it a bit like the implementation of that element.
If you are interested to learn more, MDN has a nice tutorial.
Dispatching custom events has been implemented for a long time. The filter field dispatches a custom events on itself when you key up on the field. The filter lists listen on that event, and then filter their children.
Let me know if you have more questions about the approach.
Thanks for the detailed explanation!
Thanks, Drew! Glad you like it! I’ll add filtering the headlines and styling the fields tomorrow 👍
@ddevault Addressed all three pieces of feedback. What do you think?
I chose to go with visibility: hidden for the filter field so we do not have a layout shift when the JS is loaded (which would happen if we go with display: none).
One thing I'm not sure about:
I'm not entirely sure if we should also hide the entries in the table of contents on the right for the hidden entries.
This is looking good, thanks! I have some more feedback.
When categories disappear, the space they occupied is still shown on the page. See attachment.
After reviewing this, I think the usability would be improved if we removed the categories entirely while searching and alpha-sorted all of the results together. What do you think?
I also think we can make some improvements to the search box appearance:
diff --git a/assets/_custom.scss b/assets/_custom.scss
index ce8621581..13eba4e0b 100644
--- a/assets/_custom.scss
+++ b/assets/_custom.scss
@@ -80,16 +80,27 @@ article h1 .subtitle {
filter-field {
visibility: hidden;
+ input, label {
+ display: block;
+ width: 100%;
+ }
+
+ input {
+ padding: .5rem 1rem;
+ border: 1px solid #333;
+ border-radius: .25rem;
+ background: transparent;
+ color: var(--body-font-color);
+ transition: box-shadow 0.1s linear;
+ line-height: 1.5em;
+ }
+
+ input:focus {
+ box-shadow: 0 0 2px 1px var(--color-link);
+ outline-style: none;
+ }
+
&.active {
visibility: unset;
}
}
-
-/* input field from hugo-book */
-.text-field {
- padding: .5rem;
- border: 0;
- border-radius: .25rem;
- background: var(--gray-100);
- color: var(--body-font-color);
-}
diff --git a/layouts/partials/commands/list.html b/layouts/partials/commands/list.html
index 6612d2989..89c28eba9 100644
--- a/layouts/partials/commands/list.html
+++ b/layouts/partials/commands/list.html
@@ -38,7 +38,7 @@
<filter-field id="filter-commands">
<label for="search-field">Filter</label>
- <input id="search-field" class="text-field">
+ <input id="search-field" class="text-field" placeholder="Search commands">
</filter-field>
{{ range $groups }}
I'm not entirely sure if we should also hide the entries in the table of contents on the right for the hidden entries.
I don't think we need to worry about this.
Follow-ups for a future ticket:
6178d208c9
5fbfc2bcb2
Thank you kindly for your feedback!
Will play around with the idea of alpha sorting without categories, and get back to you 👍
The failed build is just the publish step, so I guess I can ignore that, right?
5fbfc2bcb2
83b46f2420
Thank you!
The failed build is just the publish step, so I guess I can ignore that, right?
Yep, no big deal.
Thanks, Drew! I'll put the ideas of improving this on my list (hiding the headings when searching, fuzzy matching, ordering by relevance and encoding the search in the fragment)
No due date set.
No dependencies set.
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?