MediaWiki talk:Common.css

Sidebar cutoff
MediaWiki:Sidebar list grew and appears cut off in browsers in decently sized window, couldn't be scrolled to reveal below.

This might be evil code

@media screen and (min-height: 850px) { #mw-panel{ position:fixed !important; } } Lucario (talk) 02:06, 17 January 2022 (CET)


 * Tested this by injecting the CSS on the browser and it seems to work only when the browser tab is not maximized. I'm investigating the possibility of making the subsections collapsible without needing server-side changes. MediaWiki documentation has a browser-side code snippet for this but it only works with the old MonoBook skin (we use Vector skin here). - mbc07 (talk) 01:11, 1 February 2022 (CET)


 * I found a small snippet of CSS and JS that seems to do the trick, but it's quite hacky and creates an ugly "see more/less" link, unaligned from the list. I'll try to clean it up later and replace the link with an icon, if I manage get something acceptable I'll post here - mbc07 (talk) 02:25, 1 February 2022 (CET)


 * Please be mindful of mobile users, they tend to have fat finger syndrome so it's not always good idea to require extra interactions like a new arrow to collapse/uncollapse something. Uncollapsed as default might be fine but will we need to collapse something to access something else below? I was thinking just removing this code altogether will solve it once and for all as we don't really want to over complicate things. Lucario (talk) 02:56, 1 February 2022 (CET)


 * Btw, I'm not against your collapsible idea, implementing collapsible default collapsed of less important/less frequent links to keep list from becoming unwieldy long sounds like a good idea. Lucario (talk) 03:02, 1 February 2022 (CET)


 * I thought of collapsing only "Virtual Console" by default and leave the rest as-is. Still just a PoC that can't live outside the browser DevTools and that looks fugly at the moment, though - mbc07 (talk) 03:42, 1 February 2022 (CET)


 * For now I just updated the min-height check, the PoC went nowhere I'd consider usable and having the sidebar fixed if you have enough vertical space to display it is extremely useful on very long pages. Having a fixed size on the check is not nice though (especially when the links shown there changes depending on whether you're logged in or not and if you're a sysop or autoconfirmed user), so I'm now evaluating other ways of dynamically setting that property based on the side panel size... - mbc07 (talk) 08:45, 1 February 2022 (CET)


 * Thank you, it is fixed for me. I have CSS and JS knowledge so I could help you with creating dropdown versions of them. I think the viewport check should be dropped eventually to create consistency and can be helpful on long pages for users on limited window size.

window.onload = => { function ex_sb_tools{ if(sb_tools_expanded){ sb_tools_bu.style.webkitTransform = "rotate(45deg)"; sb_tools_expanded = false; col_sb_tools.style.display = "none"; } else { sb_tools_bu.style.webkitTransform = "rotate(225deg)"; sb_tools_expanded = true; col_sb_tools.style.display = "block"; }; }  var sb_tools_expanded = false; var sb_tools = document.getElementById("p-tb-label"); var col_sb_tools = document.getElementById("p-tb").getElementsByTagName("div")[0]; col_sb_tools.style.display = "none" var sb_tools_bu = document.createElement("button"); sb_tools_bu.style = "background-color:inherit; border:1px solid #666; border-width:0 2px 2px 0; padding:3px; margin-left:16px; position:absolute; -webkit-transform: rotate(45deg);" sb_tools_bu.addEventListener ("click", ex_sb_tools, false); sb_tools.appendChild(sb_tools_bu); }
 * Pure JS currently targeting "Tools" in the sidebar as the items under Virtual Console is less feasible to capture. The button styling could be tweaked a bit. Lucario (talk) 01:11, 2 February 2022 (CET)


 * I moved away from the collapsible idea because doing that via code on Common.css/Common.js is prone to breaking when the list changes. The "official" way to do that is via the CollapsibleVector extension, but that requires server-side access and will probably require updating our MediaWiki install as well (last time this didn't go as smooth as we expected and current MediaWiki versions seems to be incompatible with a few extensions we heavily rely on, like Variables). I'm a bit busy at the moment but what I plan to do is to remove the CSS for the fixed sidebar altogether and dynamically add or remove the position: fixed attribute via a resize event listener in Common.js - mbc07 (talk) 02:31, 2 February 2022 (CET)


 * I don't think it's going to be catastrophe plus we know where to find a place to update (Common.css and Common.js). I guess it depends on what is the condition that will change the id of a div at unpredictable times though. e.g. was it created dynamically and how often if it changes at unpredictable times, or was it statically coded from someplace else... Also I like the idea of taking position:fixed to the JS side so when JS didn't work the sidebar doesn't move and then the list didn't have to be cutoff. I'd really prefer something to collapse instead of seeing sidebar stop/start moving on window resize or have some ui discrepancies between different computers. Smaller screens is impacted more than larger screens on long pages so the current solution sounds little contradictory. I understand now what you meant by server-side changes. Lucario (talk) 03:28, 2 February 2022 (CET)