find another approach for the "hide the search component"

[12rambau]

The "Hide the search" component is only available when you click on a search link and allow you to remove all the "target" marked in the page. Historically it was in the secondary sidebar but it has some drawbacks. As the element was still there (but simply not visible) it was impossible to remove the secondary sidebar with an "empty" test. it was first introduced in #925 and @choldgraf solved it in another one (I didn't find it bakc sorry).

Now with the new look & fill of the theme I think the button is a bit off as it is non-centered, huge and not ideally placed if the content of the anchor is not at the very top of the page.

I was thinking about an overlay in the bottom right side (like the RDT flyout) which would work on any device and would be easy to spot.

pinging @trallard and @gabalafou as you are our display magicians now !

[gabalafou]

Display magician? I rather like that 😁

⎚🧙🏻‍♂️

Historically it was in the secondary sidebar but it has some drawbacks.

Could you tell me more about these drawbacks? I went down the rabbit hole of #925 but I still don't know what you're referring to.

Speaking of that rabbit hole, I came across an implementation of search and hide, which has some aspects that I quite like.

That made me think of something. @trallard, @smeragoel, and I are planning on doing an extensive accessibility audit of PST over the next month. I think it's quite possible that this will cause us to re-examine how we do search on the site, which will will probably affect this issue.

So can this issue wait until we've finished the audit?

[12rambau]

Could you tell me more about these drawbacks? I went down the rabbit hole of #925 but I still don't know what you're referring to.

If you look at the design of the secondary sidebar, it disapear if nothing is in it. So if on a page we remove unplug "content of this page" and we remove "show source" and "edit this page" the secondary sidebar is not displayed.

https://github.com/pydata/pydata-sphinx-theme/blob/main/src/pydata_sphinx_theme/theme/pydata_sphinx_theme/sections/sidebar-secondary.html

But when the "hide the search" was in the secodary sidebar, even when not displayed you were seeing the secondary sidebar ... empty.

[gabalafou]

Okay, so it's strictly a technical challenge, not a usability/UX drawback, is that correct?

[gabalafou]

not ideally placed if the content of the anchor is not at the very top of the page

Do you have idea if this is a common scenario though? I'm wondering how often does a user visit a ?highlight= URL that also has an anchor #down-the-page. Given the way that the highlight query string is removed by Sphinx(?) when the page loads, it seems to me that a problematic URL of this type (highlight query string plus buried anchor) has to be manually constructed, which makes me think that this is probably an edge case that should not be highly prioritized over other concerns

[12rambau]

it was happening enough for people to complain and make us change it. it's specifically a problem for landing pages

[drammock]

I encounter this ALL THE TIME both on our site and on other sites that are built with the theme. For terms that appear often in the text, the highlighting is really distracting when you want to actually read the content that you searched for.

[trallard]

Agreed 👍 the highlighting is quite distracting and that button seems now out of place / style.

Smera and I briefly discussed this last week, let me do some research and like Gabriel mentioned, we are doing a more thorough accessibility audit in the upcoming weeks so we might also gain some insights here.

[gabalafou]

Agreed 👍 the highlighting is quite distracting and that button seems now out of place / style.

I disagree. I think in the context of a search flow that the highlighting and prominent button to remove highlighting makes sense. I agree the button could be better placed or styled, but the fact that it's big and obvious is in my opinion a feature not a bug, although a feature only in the context of a search flow. Outside of a search flow, I agree with you. But I still don't understand what kind of real world path leads anyone to see a highlighted page like that outside a search flow. It's the same question I had about "not ideally placed if the content of the anchor is not at the very top of the page." I still don't understand the real world scenario steps to reproduce.

For clarity, here's an example of what I mean by search flow: user visits PST site, clicks search button, searches a term like "docs", clicks the first result and sees a page like the one screenshot.

[trallard]

For me the sore point is the button placement and the style. So if this is improved I would be happy.

Now note this one should be a button - I am not sure if we are using the sphinx design "button" but this is a genuine case of a component changing state (highlight removal).

FWIW I sometimes use this flow - search terms go to page with search matches then share the page as is with a colleague/collaborator (they get the page with the highlighted matches).

This mostly comes from someone asking me for particular docs or when we've been discussing X features in a tool. So this is one instance in which someone might land onto a highlighted page without a search.

[12rambau]

aggreed with @gabalafou I was never suggesting to remove highlithing, I just wanted to point out the button is off and may be difficult to reach in some context (scroll to the top, small screens etc...), that's why I wanted to experiment on a floating fix button.

[gabalafou]

FWIW I sometimes use this flow - search terms go to page with search matches then share the page as is with a colleague/collaborator (they get the page with the highlighted matches).

Ah, this might be where the confusion/disagreement is coming from. I suspect something got updated. Currently, our docs remove the highlight query string from the URL. So if you do a search, then click on the first search result, you get the page highlighted, but then if you copy the URL in the address bar and open it in a new tab, you'll see that there are no highlights.

The only straightforward way I can see to grab a highlighting-URL (i.e., one with the query string) for sharing with another person is to right-click a link from the list of search results and copy it that way.

There's a funny quirk, then, which is that when you share that URL, the person who opens it will see the search results highlighted, but then if they copy the URL in the browser and share it with a third person, the third person will not see a search-highlighted page. In other words, the friend that you share the search-highlighting URL with has to share the URL exactly as you shared it if they wish to preserve the highlights when sharing.