Add search-as-you-type (inline search results) feature #2093
Conversation
|
This is super cool |
|
For me it's the most wanted feature, brilliant ! |
| // Don't interfere with the default search UX on /search.html. | ||
| if (window.location.pathname.endsWith("/search.html")) { | ||
| return; | ||
| } |
There was a problem hiding this comment.
we should also account for dirhtml builds, which I think (?) will have a url like https://whatever.com/en/search/ or potentially https://whatever.com/en/search/index.html
There was a problem hiding this comment.
dirhtml was not on my radar. Will need to look into what that does to figure out how it affects the impl.
| // searchtools.js loads. | ||
| // | ||
| // Search class is defined in upstream Sphinx: | ||
| // https://github.com/sphinx-doc/sphinx/blob/master/sphinx/themes/basic/static/searchtools.js#L181 |
There was a problem hiding this comment.
link to .../blob/master/... may suffer from line number drift or otherwise go stale. Let's use a permalink to a specific repo state.
| } | ||
|
|
||
| // Create a new search-as-you-type results container. | ||
| results = document.createElement("section"); |
There was a problem hiding this comment.
@gabalafou would appreciate your perspective on what is the best node type for an appearing/disappearing list of search results, and how this can/should/will interact with things like tab focus.
| @@ -93,29 +93,50 @@ | |||
| z-index: $zindex-modal; | |||
| top: 30%; | |||
| left: 50%; | |||
| transform: translate(-50%, -50%); | |||
| transform: translate(-50%, -30%); | |||
There was a problem hiding this comment.
this change is just to make room below the modal for the results right?
| focused_element_expected_content = "1. Test of no sidebar" | ||
| assert focused_element_actual_content == focused_element_expected_content |
There was a problem hiding this comment.
this seems slightly fragile in case we (1) change our website content in a way that changes order of search results, or (2) sphinx changes their searchtools.js in a way that changes order of search results. Maybe not much to be done about that though, and we'll just fix it if/when it breaks... thoughts?
There was a problem hiding this comment.
I think I can make it more robust like this:
- Use a CSS selector like
#search-results .search li:first-of-kindto get the first node in the results - Get the
textContentof the node - Use that programmatically retrieved
textContentas the expected value
Coverage report
Click to see where and how coverage changed
This report was generated by python-coverage-comment-action |
||||||||||||||||||||||||
Fixes #1977