but that just documents the installation of the change, I don't see anything about why it was made. (I looked at the preceding couple of archived wiki pages, and didn't spot anything relevant on them either.)
My reason for asking is: I find the page behaviour this causes really annoying. e.g.
Say I'm on the front page of the site, or maybe a long search results page
I go somewhere near the bottom of the page, and find a link of possible interest
I click on the link, but find it's not what I'm looking for, so click on my browser back button to see if the next result was of more interest
Rather than returning me to the point in the page I was previously at, instead I'm put back to the top of the page, and I have to manually scroll down to find where I'd previously got to
I can see that wanting to make the form fields easilly accessible is a positive thing to have, but isn't that something that a user can easily do themselves by hitting either Tab or Home buttons? (I appreciate that it's a different story on devices with software keyboards like phones or tablets.)
I'm not asking for this change to be undone, I'm just trying to get my head around the reasons it was made. Six years on, it may be that there are technologies that might allow for a solution that keeps everyone happy e.g. CSS position:sticky https://css-tricks.com/position-sticky-2/ However, it could be that I'm missing the point entirely - it wouldn't be the first time ;-)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think there are two separate issues here. The first one is the behavior of edit pages which is what this feature request changed in 2013. The second one is the behavior of regular "bibliographic display" pages, which was changed to focus on the "Search" field back in 2006. That was before we used SourceForge to document our software changes and change requests, BTW.
It sounds like you are talking about the second issue, right? If so, then I would suggest opening a discussion on the Community Portal to see how other users feel about the current behavior and the proposed change. Personally, I find the current behavior useful in some cases, especially when I am running a bunch of searches one after another. However, there are also times when I find it irritating -- see your examples above. It's possible that something like CSS (which is much more robust and more widely supported in 2019 vs. 2006) may make a compromise solution feasible.
P.S. Sorry I haven't responded re: the test framework yet. I have been sick for the last week and it's very hard to concentrate for more than 10-15 minutes at a time.
Last edit: Ahasuerus 2019-11-12
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ah - thanks for clarification; I did an 'svn blame' on the relevant file, but it didn't show anything older than 2013, so I assumed it was all connected to this FR.
Let me see if I can hack up a quick demo using static HTML pages; if I can get something useful, then I'll post to the wiki. (I hate proposing stuff that I'm not >90% certain about how to implement, in case I end up looking a fool for not delivering on my promises.)
Re. test stuff - please don't put yourself out over that, it's nothing that needs addressing in a hurry. (I was a bit reluctant to post the prior comment on this ticket in case it came across as me nagging for your attention.)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If you scroll up and down the page, you'll see what happens to the search box. If you click on one of the title or author links (all of which point at the same page in this hacked demo) and then back, you'll find that it returns to the search at the point down the page you left it, but with the search box visible and focussed.
One thing I'd ideally like to address is having some indicator of where all the links that usually appear below the search box have disappeared to, especially if you reach the page via the back button, and had forgotten you'd scrolled halfway down the page. I think people would work it out after a couple of seconds, but it'd be nice to have something a bit more user friendly. (Unfortunately we can't make that whole nav column sticky, because it could easily be taller than the screen.) Initially Googling results in Stack Overflow posts saying there's no easy fix, but those replies are a few years old, so maybe more investigation will turn something up?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Re: "all the links that usually appear below the search box have disappeared to", I wonder if it would be feasible to make the whole navigation div (as opposed to just the Search box div) float on the left as you scroll down. It would require adding a way to access the navbar options that are below the first page, of course.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yeah, I thought about the possibility of making the whole nav fixed/sticky, but as you say, there are issues when it goes more than a screen deep, and my gut instinct tells me that you'd maybe want to limit sticky elements to ones that are no more than 600px deep (to account for 1366x768px screeens, browser chrome and toolbars, etc)
Off the top of my head, this could be achieved by the following:
Remove the image of a drawer about the search box (I must confess I never understood the point of this?)
Move the Tools Used to Create This Site, Policies and Licence sections to separate (wiki?) pages and/or links in the footer
Don't show nav links that aren't relevant in context e.g. no point showing edit links to users who aren't logged in (AFAIK?)
Have the sections as an expandable "accordion", possibly only showing the most relevant section(s) open by default. This can be done without JavaScript nowadays using and elements
However, I'd prefer that to be considered a separate feature request, as looking into which pages and users would be most affected will take a bit of effort, whereas making the search box sticky is hopefully - famous last words - a fairly simple and non-controversial change.
One side-question: do you have any stats on what browsers/versions visitors to the site are using? It looks like Google Analytics isn't currently enabled (which I'm completely on-board with :-) but you could probably get some crude but usable stats using a shell command like:
assuming your Apache logging format is similar to the one Fedora has defaulted to.
The reason I ask is that besides using "position: sticky", that demo also uses "display: flex", as an easy way to cause the nav sidebar to stretch to the bottom of the page. (Otherwise the search box is dragged from its sticky position if the nav scrolls off the top of the page.)
Both of these CSS features have been in mainline browsers for a couple of years or more, so should be supported in an era when most browsers get regular updates, but I'd rather not make assumptions if actual data is available.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, we do have Apache logs. Running that shell command produces, as you said, crude but useable results like:
800914 "Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.96 Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
621211 "The Knowledge AI"
578819 "Mozilla/5.0 (compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm)"
543576 "Mozilla/5.0 (compatible; YandexBot/3.0; +http://yandex.com/bots)"
488732 "Mozilla/5.0 (compatible; AhrefsBot/6.1; +http://ahrefs.com/robot/)"
404810 "Mozilla/5.0 (compatible; Yeti/1.1; +http://naver.me/spd)"
367025 "Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.102 Safari/537.36"
283721 "Mozilla/5.0 (compatible; DotBot/1.1; http://www.opensiteexplorer.org/dotbot, help@moz.com)"
262495 "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/77.0.3865.120 Safari/537.36"
261354 "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_1) AppleWebKit/600.2.5 (KHTML, like Gecko) Version/8.0.2 Safari/600.2.5 (Applebot/0.1; +http://www.apple.com/go/applebot)"
220731 "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:70.0) Gecko/20100101 Firefox/70.0"
and so on.
In the past whenever I used recently (for generous values of "recently") added JavaScript or CSS features, it invariably prompted user complaints and I had to roll them back. Apparently we have a surprisingly high percentage of users who access the ISFDB from work where their browsers are "locked down" and can't be upgraded.
The main question, I guess, is what is the failure mode of these CSS features? If a browser doesn't support them, will the page be still useable?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for running the stats. I should have realized the most frequently seen user agents would be dominated by bots. (I strongly suspect that "Chrome/50" visitor is likely to be a bot, even though it doesn't identify as such, given that Chrome is historically the browser that pushes auto-updates the most, and Chrome 50 dates from 2016.)
Could I ask if you could re-run that command, but with an addition grep to filter out the bots (at least the ones listed in that extract)? This should work:
Re: the newer features of CSS I used, there are two:
position: sticky; has been around on all browsers since late 2017, according to https://caniuse.com/#feat=css-sticky . For browsers that don't support it, the effect should be that the directive gets ignored i.e. the same as the current site
display: flex; is used to cause the nav column to be the same height as the main div. It's been around since late 2012 according to https://caniuse.com/#feat=flexbox . I believe the easiest alternative solution if flexbox can't be used, would be to instead add a couple of lines of JavaScript to isfdb_main.js, to get the height of the #main div, and explicitly set the height of the #nav div to be the same value, if it's smaller.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sure thing. Here is what the updated shell command generates:
621211 "The Knowledge AI"
419687 "Apache/2.2.8 (Fedora) (internal dummy connection)"
367025 "Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.102 Safari/537.36"
268029 "-"
262495 "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/77.0.3865.120 Safari/537.36"
220731 "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:70.0) Gecko/20100101 Firefox/70.0"
213028 "okhttp/3.11.0"
174801 "Mozilla/5.0 (compatible; MegaIndex.ru/2.0; +http://megaindex.com/crawler)"
169498 "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:69.0) Gecko/20100101 Firefox/69.0"
100038 "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.70 Safari/537.36"
83728 "Mozilla/5.0 (Linux; Android 7.0; FRD-AL00 Build/HUAWEIFRD-AL00; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/53.0.2785.49 Mobile MQQBrowser/6.2 TBS/043602 Safari/537.36 MicroMessenger/6.5.16.1120 NetType/WIFI Language/zh_CN"
83429 "Mozilla/5.0(Linux;Android 5.1.1;OPPO A33 Build/LMY47V;wv) AppleWebKit/537.36(KHTML,link Gecko) Version/4.0 Chrome/42.0.2311.138 Mobile Safari/537.36 Mb2345Browser/9.0"
83428 "Mozilla/5.0(Linux;Android 5.1.1;OPPO A33 Build/LMY47V;wv) AppleWebKit/537.36(KHTML,link Gecko) Version/4.0 Chrome/43.0.2357.121 Mobile Safari/537.36 LieBaoFast/4.51.3"
83387 "Mozilla/5.0(Linux;U;Android 5.1.1;zh-CN;OPPO A33 Build/LMY47V) AppleWebKit/537.36(KHTML,like Gecko) Version/4.0 Chrome/40.0.2214.89 UCBrowser/11.7.0.953 Mobile Safari/537.36"
73737 "Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/77.0.3865.120 Safari/537.36"
70028 "Mozilla/5.0 (compatible; Seekport Crawler; http://seekport.com/)"
68897 "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36 Edge/18.18362"
67537 "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.87 Safari/537.36"
63934 "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_5) AppleWebKit/537.36 (KHTML, like Gecko)Chrome/68.0.3440.84 Safari/537.36"
61674 "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/77.0.3865.90 Safari/537.36"
54786 "Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:70.0) Gecko/20100101 Firefox/70.0"
51871 "Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:70.0) Gecko/20100101 Firefox/70.0"
48085 "Mozilla/5.0 (X11; CrOS x86_64 12371.75.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/77.0.3865.105 Safari/537.36"
46571 "Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:69.0) Gecko/20100101 Firefox/69.0"
45557 "Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; DTS Agent"
44802 "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.140 Safari/537.36 Edge/18.17763"
37277 "Mozilla/5.0 (iPhone; CPU iPhone OS 13_1_3 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.0.1 Mobile/15E148 Safari/604.1"
35968 "Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko"
35701 "Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; rv:11.0) like Gecko"
30070 "Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:69.0) Gecko/20100101 Firefox/69.0"
26061 "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.0.1 Safari/605.1.15"
24425 "Sogou web spider/4.0(+http://www.sogou.com/docs/help/webmasters.htm#07)"
21938 "Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.70 Safari/537.36"
21401 "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3626.121 Safari/537.36"
20012 "Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/77.0.3865.90 Safari/537.36"
19691 "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:70.0) Gecko/20100101 Firefox/70.0"
19041 "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:69.0) Gecko/20100101 Firefox/69.0"
18747 "Mozilla/5.0 (compatible; +centuryb.o.t9[at]gmail.com)"
18673 "Scrapy/1.5.1 (+https://scrapy.org)"
18561 "Mozilla/5.0 (iPhone; CPU iPhone OS 13_1_2 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.0.1 Mobile/15E148 Safari/604.1"
etc.
Re: the proposed JavaScript-based solution, I am sure it would work, but first we need to address the elephant in the room. (The pink one, under the chair on the left.) Early on we decided that we would only use JavaScript on edit pages. Regular bibliographic pages do not use JavaScript at this time.
The original reason was that we wanted to support old browsers like Lynx which didn't handle JavaScript well -- or at all. These days Lynx is hardly ever seen (less than 20 hits in the last 2 weeks), so that's less of a concern. However, there are a lot of users out there who browse the Web with JavaScript disabled by default, only turning it on for trusted sites. NoScript alone reportedly has over 4 million users, myself included.
Having said that, the world keeps changing and we need to periodically revisit old design decisions to make sure that they still make sense. But it needs to be a conscious decision before we can start adding JS snippets to bibliographic pages.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for redoing the stats, I'll have a proper dig into them later.
Re. JavaScript, for this specific issue, I think the problem points the way to the solution, in that - as I understand it - the issue with scrolling/focussing only occurs because JavaScript overrides the default browser behaviour on page load, thus if the "unbreaking" only works when JS is enabled, then that should be fine. (There's a bit more to this problem than that, but I think the browser configurations that need to be tested will be much reduced from most other front-end issues.)
Re. JavaScript dependency generally, I don't disagree with you generally. Whilst I don't disable JS by default, I do have extensions installed in most of my browsers that allow me to disable it easily via a toolbar button, plus I have other extensions installed that block (IMHO) dodgy tracking JS like Google Analytics. Similarly, all the stuff I've built using ISFDB data, like the Goodreads ratings<->awards or historical gender split charts, all either generate bitmap images, or SVGs which JS interactivity enhancements, but which are still usable without. I hate the current vogue in (most) front-end dev circles to do everything in JavaScript, and avoid it like the plague.
BTW, if it's OK with you, I'll create a separate FR for this enhancement. So far I've only seen one comment to my post on the Community Portal wiki page, which seemed in favour, so hopefully this change is broadly acceptable, assuming browser compatibility issues are covered.
EDIT: sorry, only just noticed you'd added a comment to that wiki page section, I think from before I'd posted this response.
Last edit: ErsatzCulture 2019-11-12
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I agree that this functionality deserves a separate FR regardless of how we end up proceeding.
Re: JavaScript, yes, the "set focus" functionality is only available if JavaScript is enabled. If it is disabled, default browser behavior is what the user will experience. I'll respond re: the large implications later, when my brain is less fried.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Implemented in:
Installed in r2013-107. Closing the ticket.
Apologies for digging up ancient history, but is there any documentation about the background for this change? I've found
http://www.isfdb.org/wiki/index.php/ISFDB:Community_Portal/Archive/Archive30#Patch_r2013-107_.28auto-focus_for_edir_pages.29
but that just documents the installation of the change, I don't see anything about why it was made. (I looked at the preceding couple of archived wiki pages, and didn't spot anything relevant on them either.)
My reason for asking is: I find the page behaviour this causes really annoying. e.g.
I can see that wanting to make the form fields easilly accessible is a positive thing to have, but isn't that something that a user can easily do themselves by hitting either Tab or Home buttons? (I appreciate that it's a different story on devices with software keyboards like phones or tablets.)
I'm not asking for this change to be undone, I'm just trying to get my head around the reasons it was made. Six years on, it may be that there are technologies that might allow for a solution that keeps everyone happy e.g. CSS position:sticky https://css-tricks.com/position-sticky-2/ However, it could be that I'm missing the point entirely - it wouldn't be the first time ;-)
I think there are two separate issues here. The first one is the behavior of edit pages which is what this feature request changed in 2013. The second one is the behavior of regular "bibliographic display" pages, which was changed to focus on the "Search" field back in 2006. That was before we used SourceForge to document our software changes and change requests, BTW.
It sounds like you are talking about the second issue, right? If so, then I would suggest opening a discussion on the Community Portal to see how other users feel about the current behavior and the proposed change. Personally, I find the current behavior useful in some cases, especially when I am running a bunch of searches one after another. However, there are also times when I find it irritating -- see your examples above. It's possible that something like CSS (which is much more robust and more widely supported in 2019 vs. 2006) may make a compromise solution feasible.
P.S. Sorry I haven't responded re: the test framework yet. I have been sick for the last week and it's very hard to concentrate for more than 10-15 minutes at a time.
Last edit: Ahasuerus 2019-11-12
Ah - thanks for clarification; I did an 'svn blame' on the relevant file, but it didn't show anything older than 2013, so I assumed it was all connected to this FR.
Let me see if I can hack up a quick demo using static HTML pages; if I can get something useful, then I'll post to the wiki. (I hate proposing stuff that I'm not >90% certain about how to implement, in case I end up looking a fool for not delivering on my promises.)
Re. test stuff - please don't put yourself out over that, it's nothing that needs addressing in a hurry. (I was a bit reluctant to post the prior comment on this ticket in case it came across as me nagging for your attention.)
Here's a quick proof-of-concept (with test styling on some borders, so not fit for wider consumption in this form):
https://sf.ersatzculture.com/temp/search.html
If you scroll up and down the page, you'll see what happens to the search box. If you click on one of the title or author links (all of which point at the same page in this hacked demo) and then back, you'll find that it returns to the search at the point down the page you left it, but with the search box visible and focussed.
One thing I'd ideally like to address is having some indicator of where all the links that usually appear below the search box have disappeared to, especially if you reach the page via the back button, and had forgotten you'd scrolled halfway down the page. I think people would work it out after a couple of seconds, but it'd be nice to have something a bit more user friendly. (Unfortunately we can't make that whole nav column sticky, because it could easily be taller than the screen.) Initially Googling results in Stack Overflow posts saying there's no easy fix, but those replies are a few years old, so maybe more investigation will turn something up?
I think it's a very good idea.
Re: "all the links that usually appear below the search box have disappeared to", I wonder if it would be feasible to make the whole navigation div (as opposed to just the Search box div) float on the left as you scroll down. It would require adding a way to access the navbar options that are below the first page, of course.
Yeah, I thought about the possibility of making the whole nav fixed/sticky, but as you say, there are issues when it goes more than a screen deep, and my gut instinct tells me that you'd maybe want to limit sticky elements to ones that are no more than 600px deep (to account for 1366x768px screeens, browser chrome and toolbars, etc)
Off the top of my head, this could be achieved by the following:
elements
However, I'd prefer that to be considered a separate feature request, as looking into which pages and users would be most affected will take a bit of effort, whereas making the search box sticky is hopefully - famous last words - a fairly simple and non-controversial change.
One side-question: do you have any stats on what browsers/versions visitors to the site are using? It looks like Google Analytics isn't currently enabled (which I'm completely on-board with :-) but you could probably get some crude but usable stats using a shell command like:
assuming your Apache logging format is similar to the one Fedora has defaulted to.
The reason I ask is that besides using "position: sticky", that demo also uses "display: flex", as an easy way to cause the nav sidebar to stretch to the bottom of the page. (Otherwise the search box is dragged from its sticky position if the nav scrolls off the top of the page.)
Both of these CSS features have been in mainline browsers for a couple of years or more, so should be supported in an era when most browsers get regular updates, but I'd rather not make assumptions if actual data is available.
Yes, we do have Apache logs. Running that shell command produces, as you said, crude but useable results like:
800914 "Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.96 Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
621211 "The Knowledge AI"
578819 "Mozilla/5.0 (compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm)"
543576 "Mozilla/5.0 (compatible; YandexBot/3.0; +http://yandex.com/bots)"
488732 "Mozilla/5.0 (compatible; AhrefsBot/6.1; +http://ahrefs.com/robot/)"
404810 "Mozilla/5.0 (compatible; Yeti/1.1; +http://naver.me/spd)"
367025 "Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.102 Safari/537.36"
283721 "Mozilla/5.0 (compatible; DotBot/1.1; http://www.opensiteexplorer.org/dotbot, help@moz.com)"
262495 "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/77.0.3865.120 Safari/537.36"
261354 "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_1) AppleWebKit/600.2.5 (KHTML, like Gecko) Version/8.0.2 Safari/600.2.5 (Applebot/0.1; +http://www.apple.com/go/applebot)"
220731 "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:70.0) Gecko/20100101 Firefox/70.0"
and so on.
In the past whenever I used recently (for generous values of "recently") added JavaScript or CSS features, it invariably prompted user complaints and I had to roll them back. Apparently we have a surprisingly high percentage of users who access the ISFDB from work where their browsers are "locked down" and can't be upgraded.
The main question, I guess, is what is the failure mode of these CSS features? If a browser doesn't support them, will the page be still useable?
Thanks for running the stats. I should have realized the most frequently seen user agents would be dominated by bots. (I strongly suspect that "Chrome/50" visitor is likely to be a bot, even though it doesn't identify as such, given that Chrome is historically the browser that pushes auto-updates the most, and Chrome 50 dates from 2016.)
Could I ask if you could re-run that command, but with an addition grep to filter out the bots (at least the ones listed in that extract)? This should work:
Also, just grabbing the moderator page URLs should give a good idea of what browsers the most active (=most likely to complain ;-) users use:
Re: the newer features of CSS I used, there are two:
Sure thing. Here is what the updated shell command generates:
621211 "The Knowledge AI"
419687 "Apache/2.2.8 (Fedora) (internal dummy connection)"
367025 "Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.102 Safari/537.36"
268029 "-"
262495 "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/77.0.3865.120 Safari/537.36"
220731 "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:70.0) Gecko/20100101 Firefox/70.0"
213028 "okhttp/3.11.0"
174801 "Mozilla/5.0 (compatible; MegaIndex.ru/2.0; +http://megaindex.com/crawler)"
169498 "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:69.0) Gecko/20100101 Firefox/69.0"
100038 "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.70 Safari/537.36"
83728 "Mozilla/5.0 (Linux; Android 7.0; FRD-AL00 Build/HUAWEIFRD-AL00; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/53.0.2785.49 Mobile MQQBrowser/6.2 TBS/043602 Safari/537.36 MicroMessenger/6.5.16.1120 NetType/WIFI Language/zh_CN"
83429 "Mozilla/5.0(Linux;Android 5.1.1;OPPO A33 Build/LMY47V;wv) AppleWebKit/537.36(KHTML,link Gecko) Version/4.0 Chrome/42.0.2311.138 Mobile Safari/537.36 Mb2345Browser/9.0"
83428 "Mozilla/5.0(Linux;Android 5.1.1;OPPO A33 Build/LMY47V;wv) AppleWebKit/537.36(KHTML,link Gecko) Version/4.0 Chrome/43.0.2357.121 Mobile Safari/537.36 LieBaoFast/4.51.3"
83387 "Mozilla/5.0(Linux;U;Android 5.1.1;zh-CN;OPPO A33 Build/LMY47V) AppleWebKit/537.36(KHTML,like Gecko) Version/4.0 Chrome/40.0.2214.89 UCBrowser/11.7.0.953 Mobile Safari/537.36"
73737 "Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/77.0.3865.120 Safari/537.36"
70028 "Mozilla/5.0 (compatible; Seekport Crawler; http://seekport.com/)"
68897 "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36 Edge/18.18362"
67537 "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.87 Safari/537.36"
63934 "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_5) AppleWebKit/537.36 (KHTML, like Gecko)Chrome/68.0.3440.84 Safari/537.36"
61674 "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/77.0.3865.90 Safari/537.36"
54786 "Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:70.0) Gecko/20100101 Firefox/70.0"
51871 "Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:70.0) Gecko/20100101 Firefox/70.0"
48085 "Mozilla/5.0 (X11; CrOS x86_64 12371.75.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/77.0.3865.105 Safari/537.36"
46571 "Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:69.0) Gecko/20100101 Firefox/69.0"
45557 "Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt; DTS Agent"
44802 "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.140 Safari/537.36 Edge/18.17763"
37277 "Mozilla/5.0 (iPhone; CPU iPhone OS 13_1_3 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.0.1 Mobile/15E148 Safari/604.1"
35968 "Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko"
35701 "Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; rv:11.0) like Gecko"
30070 "Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:69.0) Gecko/20100101 Firefox/69.0"
26061 "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.0.1 Safari/605.1.15"
24425 "Sogou web spider/4.0(+http://www.sogou.com/docs/help/webmasters.htm#07)"
21938 "Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.70 Safari/537.36"
21401 "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3626.121 Safari/537.36"
20012 "Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/77.0.3865.90 Safari/537.36"
19691 "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:70.0) Gecko/20100101 Firefox/70.0"
19041 "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:69.0) Gecko/20100101 Firefox/69.0"
18747 "Mozilla/5.0 (compatible; +centuryb.o.t9[at]gmail.com)"
18673 "Scrapy/1.5.1 (+https://scrapy.org)"
18561 "Mozilla/5.0 (iPhone; CPU iPhone OS 13_1_2 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.0.1 Mobile/15E148 Safari/604.1"
etc.
Re: the proposed JavaScript-based solution, I am sure it would work, but first we need to address the elephant in the room. (The pink one, under the chair on the left.) Early on we decided that we would only use JavaScript on edit pages. Regular bibliographic pages do not use JavaScript at this time.
The original reason was that we wanted to support old browsers like Lynx which didn't handle JavaScript well -- or at all. These days Lynx is hardly ever seen (less than 20 hits in the last 2 weeks), so that's less of a concern. However, there are a lot of users out there who browse the Web with JavaScript disabled by default, only turning it on for trusted sites. NoScript alone reportedly has over 4 million users, myself included.
Having said that, the world keeps changing and we need to periodically revisit old design decisions to make sure that they still make sense. But it needs to be a conscious decision before we can start adding JS snippets to bibliographic pages.
Thanks for redoing the stats, I'll have a proper dig into them later.
Re. JavaScript, for this specific issue, I think the problem points the way to the solution, in that - as I understand it - the issue with scrolling/focussing only occurs because JavaScript overrides the default browser behaviour on page load, thus if the "unbreaking" only works when JS is enabled, then that should be fine. (There's a bit more to this problem than that, but I think the browser configurations that need to be tested will be much reduced from most other front-end issues.)
Re. JavaScript dependency generally, I don't disagree with you generally. Whilst I don't disable JS by default, I do have extensions installed in most of my browsers that allow me to disable it easily via a toolbar button, plus I have other extensions installed that block (IMHO) dodgy tracking JS like Google Analytics. Similarly, all the stuff I've built using ISFDB data, like the Goodreads ratings<->awards or historical gender split charts, all either generate bitmap images, or SVGs which JS interactivity enhancements, but which are still usable without. I hate the current vogue in (most) front-end dev circles to do everything in JavaScript, and avoid it like the plague.
BTW, if it's OK with you, I'll create a separate FR for this enhancement. So far I've only seen one comment to my post on the Community Portal wiki page, which seemed in favour, so hopefully this change is broadly acceptable, assuming browser compatibility issues are covered.
EDIT: sorry, only just noticed you'd added a comment to that wiki page section, I think from before I'd posted this response.
Last edit: ErsatzCulture 2019-11-12
I agree that this functionality deserves a separate FR regardless of how we end up proceeding.
Re: JavaScript, yes, the "set focus" functionality is only available if JavaScript is enabled. If it is disabled, default browser behavior is what the user will experience. I'll respond re: the large implications later, when my brain is less fried.