Allow for search query in URL

[ericcornelissen]

Not hugely important, but might be nice to have 😎

What I mean by this is to allow for URLs such as https://simpleicons.org/?q=angular (or a similar format), which would result in the browser initializing the page as follows:

DISCLAIMER: Given the nature of Jekyll, as far as I know it is not possible to implement this using HTTP get request. Hence, it must be implemented using JavaScript on top of the existing search feature. This will require manipulating the browser history to update the URL in the users browser, which is only supported by modern browsers (but I expect this is not a problem given our target audience).

Another issue is related to #649 where user A sharing a query-link with user B that has JavaScript disabled might cause some confusing between these two users.

Thoughts?

[birjj]

We might be able to do some fancy hacking with :target in CSS (and # instead of ?q= in the URL) so that this doesn't rely on JS.

[Edit] Although it is possible, it doesn't work with history.replaceState. This means that the browser's back button is completely broken when using this technique, and that comes on top of the massive amounts of CSS required.

A pure JS solution is probably preferable.

[ericcornelissen]

After some fiddling I wasn't able to get it working properly, the closest I got was the snippet below but this doesn't hide icons before the selected icon:

.grid-item:target {
  display: block;
}
.grid-item:target ~ .grid-item {
  display: none;
}

Another problem with this approach would be that you cannot share a query that gives back multiple results, although (if someone can get your suggestion working) we could use it as a fallback method, but that can still be a point of confusion...

[birjj]

@ericcornelissen See the edit of my previous comment. While it is possible, it brings way too many cons along with it 😞

[ericcornelissen]

Although it is possible, it doesn't work with history.replaceState. This means that the browser's back button is completely broken when using this technique...

Can you elaborate on that @birjolaxew? As far as I know history.replaceState() can be used (but isn't in your example because of the limitations in Codepen, I think) but that would break the back-button, see MDN. The method used in the pen, window.location.hash = "#"+val;, works with the back button (at least when I test it locally).

I guess what you are looking for is the history.pushState() method, see MDN, which has a few advantages listed, but when I tried to use it locally the page didn't reload 😞

(I only tested this in Chrome)

... on top of the massive amounts of CSS required.

That problem can be solved by using Sass via Jekyll, as they do in the codepen example.

[birjj]

@ericcornelissen .replaceState/.pushState don't apply the :target selector in any modern browser (see discussion on whatwg). You can update the URL, sure, but the actual effect we're looking for isn't applied.

As for the back button, imagine this scenario: you google for icons and stumble upon our site. You search for an icon. Then you search for another. Then you search for a third. You repeat this a few times. Then you want to go back to google.

If you use location.hash = ..., you'll have to press the back button as many times as you searched. If you use .replaceState you don't. That's what I mean by "breaks the back button" - it uses the back button for a purpose the user doesn't expect.

---

Regardless, a purely JS-based solution is definitely the best. This would also allow us to do partial searches (i.e. the hash is always equal to the search string, so that e.g. #adobe shows all Adobe icons)

[styfle]

imagine this scenario: you google for icons and stumble upon our site. You search for an icon. Then you search for another. Then you search for a third. You repeat this a few times. Then you want to go back to google.

This is pretty normal behavior nowadays.
If you do a google search for "gmail", click a few things in Gmail, then click back you are still on Gmail.

The solution is the hold the back button and you can see your browsing history. Then you can select Google to jump back to Google if you wish or however far back you want to go.

[davidklebanoff]

@styfle Even if some consider it normal, which I disagree with, it's still very much bad practice and hated by many. It's called back button hijacking.

[ericcornelissen]

@birjolaxew, thanks for the example now I get what you're trying to say, and I agree that is not desirable. And indeed, as you said a purely JS approach is better because it allows for partial searches.

But, this discussion did give me an idea to solve to confusion problem described before 🎉 We can use a :target selector which shows a message explaining the situation if the user has JavaScript disabled and hide it when the user has JavaScript enabled, similar to what I did in #649

[birjj]

@ericcornelissen I think a better way to do that would be to use the <noscript> tag. Unfortunately :target can't be used on anything but the element whose ID exactly matches the hash, so if the hash is #adobe (or any other string we haven't accounted for) the message wouldn't show.

Note that if we use ?q=..., we can also see the data in our Google Analytics, so I think that's the way to go 😄

[ericcornelissen]

@birjolaxew Good points 👍

Edit: oops