Skip to content
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

x/pkgsite: search in page is made less useful by hidden content #42653

Open
mvdan opened this issue Nov 17, 2020 · 6 comments
Open

x/pkgsite: search in page is made less useful by hidden content #42653

mvdan opened this issue Nov 17, 2020 · 6 comments

Comments

@mvdan
Copy link
Member

@mvdan mvdan commented Nov 17, 2020

Steps to reproduce the good godoc.org behavior:

  1. Go to https://godoc.org/github.com/dgraph-io/badger
  2. Press Ctrl-F (or whichever "search in page" shortcut)
  3. Type "NewIterator"
  4. Get taken straight to "func (txn *Txn) NewIterator(opt IteratorOptions) *Iterator", its first occurrence - in the index

Now, on pkgsite:

  1. Go to https://pkg.go.dev/github.com/dgraph-io/badger/v2@v2.2007.2
  2. Press Ctrl-F (or whichever "search in page" shortcut)
  3. Type "NewIterator"
  4. The first result is about a quarter of the page in, but I don't see a match. Weird. Press enter again for the next match.
  5. Still an invisible/hidden match. I have to press enter a few more times to get taken to the index, the visible result I want.

Another way to look at it is that the search on godoc.org results in 6 matches, but the same search results in 10 matches on pkgsite. The first four matches are hidden, which make up for the difference with godoc.org.

Can we get rid of those four hidden matches altogether? Especially since they somehow match before the index, which is very close to the top.

@mvdan mvdan added the pkgsite label Nov 17, 2020
@gopherbot gopherbot added this to the Unreleased milestone Nov 17, 2020
@mvdan
Copy link
Member Author

@mvdan mvdan commented Nov 17, 2020

The reason I find this issue pretty significant is that I heavily rely on Ctrl-F to quickly find an item in godoc's index. This does not work well on pkgsite, as shown above.

@jamalc jamalc modified the milestones: Unreleased, pkgsite/frontend Nov 17, 2020
@jamalc jamalc self-assigned this Nov 23, 2020
@gopherbot
Copy link

@gopherbot gopherbot commented Nov 23, 2020

Change https://golang.org/cl/272608 mentions this issue: content/static: expand readme when browser text search is activated

@mvdan
Copy link
Member Author

@mvdan mvdan commented Nov 23, 2020

I don't think the fix above is what we want, though. When I search the page, I want the first hits to match the page index, not the README.

@jamalc
Copy link
Member

@jamalc jamalc commented Nov 23, 2020

There isn't a simple way to get rid of the hidden matches but I think the best solution here is to make the hidden content visible because it does contain the text from the search. For your particular use case using the jump to Identifier feature by pressing the 'F' key would get you to the function right away.

@mvdan
Copy link
Member Author

@mvdan mvdan commented Nov 23, 2020

Hm. I can live with using F instead of ^F, though I admit that will be fairly painful as it's hard to retrain muscle memory. It's unfortunate that the plain page search is less useful in pkgsite compared to godoc - I'm surprised that there is no way to make hidden content not match page search, or to just not have the hidden text be present in the HTML at all.

@jamalc
Copy link
Member

@jamalc jamalc commented Nov 23, 2020

I like being able to search through all the text without having to expand the readme but do see your point. I'd like to merge this for now so that the experience doesn't feel completely broken and add @Joanne881107 @fflewddur for product / UX input.

We could keep the hidden content out of text search by picking a split point within the readme (maybe the second heading for markdown files and N characters/words/lines for text files) then rendering the two sections in separate elements with the second hidden from the page. This would mean the collapsed section size will vary but it would create a cleaner break within the readme section.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants
You can’t perform that action at this time.