15,189
edits
 |
Progress Continues
We've already had 21582 updates since Dolphin 5.0. Keep up with Dolphin's continuing progress through the Dolphin Blog: February, March, and April 2024 Dolphin Progress Report. |
 |
The Dolphin Emulator Wiki needs your help! Dolphin can play thousands of games, and changes are happening all the time. Help us keep up! Join in and help us make this the best resource for Dolphin. |
MediaWiki talk:Common.css: Difference between revisions
m
→Sidebar cutoff: typo
mNo edit summary |
m (→Sidebar cutoff: typo) |
||
| Line 34: | Line 34: | ||
::::::: 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 when some of them couldn't be collapsed. 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. [[User:Lucario|Lucario]] ([[User talk:Lucario|talk]]) 03:28, 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 when some of them couldn't be collapsed. 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. [[User:Lucario|Lucario]] ([[User talk:Lucario|talk]]) 03:28, 2 February 2022 (CET) | ||
:::::::: Like I mentioned before I'm not too fond of hacking up collapsible items via JS when a proper extension exists for that (even though we can't install it at the moment) and I also didn't find any solution I'd consider acceptable for the | :::::::: Like I mentioned before I'm not too fond of hacking up collapsible items via JS when a proper extension exists for that (even though we can't install it at the moment) and I also didn't find any solution I'd consider acceptable for the horizontal scrolling issue you pointed when the sidebar position is fixed. I might (or might not) revisit this "problem" in the future but for now I just entirely dropped the CSS responsible for conditionally locking the sidebar position on screen and the padding between the sidebar content and the logo (our logo already has a lot of vertical padding on itself, no need to add more) - [[User:mbc07|mbc07]] ([[User talk:mbc07|talk]]) 05:10, 8 February 2022 (CET) | ||
::::::::: Understandable. The position fixed may be convenient for long pages but was not the greatest idea considering too many of the side effects. [[User:Lucario|Lucario]] ([[User talk:Lucario|talk]]) 05:30, 8 February 2022 (CET) | ::::::::: Understandable. The position fixed may be convenient for long pages but was not the greatest idea considering too many of the side effects. [[User:Lucario|Lucario]] ([[User talk:Lucario|talk]]) 05:30, 8 February 2022 (CET) | ||
== So the menu flying problem == | == So the menu flying problem == | ||