It needs to so that it can search on the backend and show you all instances of that search rather than just what the currently loaded DOM elements contain.
On pretty much any other web page, Ctrl+F will search whatever is on the page; why should Discourse be any different?
I don't mind them having a server-side search function that actually searches the entire thread. I do mind having a heavily-used shortcut hijacked to behave in a non-standard way.
Because to remain performant, modem sites remove elements that have been scrolled too far off the page. So native ctrl + f would not be searching very much at all.
I don't see the problem with this tbh. When you create a JS app, you lose a lot of the native features of the browser and it becomes your own responsibility to reimplement them in a correct way. As long as the site pulls it off flawlessly, this is ok to me.
And from what I have seen, discourse does do this well.
This is a great example of a "feature" that seems to make sense but, for reasons I can't quite put my finger on, really bothers me.
Maybe it's that Discourse's search functionality didn't really work well, or suddenly started searching across threads rather than only the current one (IIRC); maybe it's that it's the only system I can think of (other than google docs) that hijacks the shortcut, but it gave me a very negative first impression of the tool.
For another similar example, the Blendle website (note - not the app!) hijacks Esc when reading an article, and interprets it as a shortcut to return to the main page of the site. I actually reported it as an issue to them, and they said it's by design and not going to change. :/
On most modern apps, this is pretty much just what is on the screen right now + a little on the top and bottom. The elements get removed/reused once they scroll off the page for performance.
I only see this as an issue if the site does not reimplement find so that it is able to deal with this.
Their method seems really efficient to me. It infinitely scrolls, feels like it's actually native, and hijacks the shortcuts to make them work as if it was native.
I really like their timeline scrollbar as well which lets you easily move through hundreds of posts very quickly and has become a pattern in many apps like Google Photos and Telegram.
This drives me crazy. I feel not enough people are complaining about this. Is finding text from the currently-loaded discussion such a niche thing?
I second the other comments, XenForo is the best currently.
I honestly usually give up and close the tab when I press Ctrl+F and this happens.
Hitting it a second time will open your browser's regular search dialog
Just can't guarantee it will be useful
It needs to so that it can search on the backend and show you all instances of that search rather than just what the currently loaded DOM elements contain.
On pretty much any other web page, Ctrl+F will search whatever is on the page; why should Discourse be any different?
I don't mind them having a server-side search function that actually searches the entire thread. I do mind having a heavily-used shortcut hijacked to behave in a non-standard way.
Try pressing CTRL+F twice and see what happens
1 reply →
Because to remain performant, modem sites remove elements that have been scrolled too far off the page. So native ctrl + f would not be searching very much at all.
I don't see the problem with this tbh. When you create a JS app, you lose a lot of the native features of the browser and it becomes your own responsibility to reimplement them in a correct way. As long as the site pulls it off flawlessly, this is ok to me.
And from what I have seen, discourse does do this well.
1 reply →
This is a great example of a "feature" that seems to make sense but, for reasons I can't quite put my finger on, really bothers me.
Maybe it's that Discourse's search functionality didn't really work well, or suddenly started searching across threads rather than only the current one (IIRC); maybe it's that it's the only system I can think of (other than google docs) that hijacks the shortcut, but it gave me a very negative first impression of the tool.
For another similar example, the Blendle website (note - not the app!) hijacks Esc when reading an article, and interprets it as a shortcut to return to the main page of the site. I actually reported it as an issue to them, and they said it's by design and not going to change. :/
What if I want to search only currently loaded DOM elements?
Usually you repeat the search hotkey to activate the browser's native search function.
On most modern apps, this is pretty much just what is on the screen right now + a little on the top and bottom. The elements get removed/reused once they scroll off the page for performance.
I only see this as an issue if the site does not reimplement find so that it is able to deal with this.
6 replies →
That seems like a direct consequence of the non efficient infinite scrolling that they implemented.
Their method seems really efficient to me. It infinitely scrolls, feels like it's actually native, and hijacks the shortcuts to make them work as if it was native.
I really like their timeline scrollbar as well which lets you easily move through hundreds of posts very quickly and has become a pattern in many apps like Google Photos and Telegram.
2 replies →
IMO, that should not even be possible. Browsers need to start being user agents again.