== Steps to reproduce
# Visit http://patchdemo.wmflabs.org/wikis/d2f57fcf67fb2a5e6e17d6158813e6e5/w/index.php/Blah
# Login with username: `patchdemo` and password: `patchdemo123`
== Expected results
When sidebar is longer than content, it pushes the footer down resulting in no overlap.
== Actual results
When sidebar is longer than content, sidebar gives no care in the world and floods the footer. It is also possible for the sidebar to extend well past the footer depending on how long it is.
== Environments observed
Can be observed locally when logged in with modern Vector on and your LocalSettings.php contains `$wgVectorLayoutMaxWidth = true;`
Will also be apparent if/when T246420 is deployed and turned on. One example of where this would occur is at https://en.wikipedia.org/wiki/Wikipedia:Article_wizard.
== Developer Notes
**//Why does this happen?//**
The problem occurs because the sidebar is absolutely positioned, and therefore cannot push the footer down with its height. Note that the sidebar is also absolutely positioned in legacy Vector, but the overlap does not occur with the footer because the footer is made to be the width of the content. Therefore, the sidebar has its own "lane" and never touches the footer.
**//Why is the sidebar absolutely positioned?//**
In an effort to maintain our DOM order for accessibility reasons (T240489), the content continues to be ordered before the header and before the sidebar. Therefore, both the header and sidebar are absolutely positioned in order to accommodate this constraint and make these elements visually appear before the content. I'm not sure if there is any other way to meet this constraint //without// absolutely positioning these elements.
**//What is the fix?//**
There are several ways we could go about this each one with its own suck factor. Other suggestions are welcome:
**Make the content have a min-height of some arbitrary value //x// or make it have a min-height of the viewport height:**
- This puts a bandaid on the problem and may mitigate its frequency, but we are really just guessing/hoping that the sidebar will not be longer than that //x// height value. The sidebar's height is not within our control and may still exceed //x//.
**Change the design and make the footer width match the content width. This might look something like:**
- Are we okay with the sidebar extending //past// the footer? (This solution would not address that).
- What do we do about the grey area (e.g. if the footer spills into the grey area). Do we remove the grey and replace with white?
- The `mw-page-container` currently has an `overflow: hidden` style applied to it to hide the sidebar when it is collapsing. If we keep the style then the sidebar could also be hidden if it extends past the page container. What to do about this?
**Change the DOM order: Move the sidebar next to the content and remove its absolute positioning**
- Are we okay moving the DOM order around and accepting whatever effect it has on accessibility (where sidebar might be ordered before content)? There was a ton of time spent on T246420 trying to maintain/achieve a DOM order that kept the content above the header/sidebar with this consideration in mind and a lot of time carefully thinking about the tab order and trying to make it work with the checkbox hack. If we go this route, will probably need to have these discussions again and T240489 may very well be a blocker for this task.
- Even if we go this route, what do we use to position the sidebar next to the content? Floats? Flexbox? I took a stab of what this would look like using a floated sidebar. It seemed to work mostly well but would need to look into addressing a bug when sidebar is closed and viewport width is small.
- POC: https://gerrit.wikimedia.org/r/c/mediawiki/skins/Vector/+/610458 (but need to address a bug with sidebar closed at small widths)