Fixed height and y-overflow

[aclist]

Need to determine whether:

• Modal should be a fixed height with overflow content therein flowed through a scrollbar
• Modal should just cover the entire screen
  • Affects dock button, which should be dropped in that case
• To open the entire menu in a new tab

Consider the possibility/likelihood of more verbose information/configs being added in the future and the need to make things feel uncramped.

[artillect]

Should be pretty easy to do the first two with a little bit of CSS, I'll get on it. I'm not sure if we'll need to open it in a new tab as long as we make the UI responsive

[aclist]

OK, I've added a sticky footer that contains a magazine link and bug report link and should be more conducive to a full-bleed modal.

[aclist]

Three workarounds for wanting to preview the results without the modal occluding the page, in ascending order of desirability.

First, let's assume that we are covering the page and adding a scrollbar.

1. Image tooltips. Hover an icon and you'll see a sample image or gif of what the feature does. Counterpoint: I really don't like this in principle, too fancy and overengineered, need to load external images or base64 encode them, adds overhead with processing the images, and need to load some fancy tooltip popup logic.
2. Lightbulb icon at the top to "dim" the modal contents so you can see through to the parent window. Counterpoint: seems a bit gimmicky, and dimming may cause things to look not exactly as they actually would.
3. Icon at the top to "roll up" the modal into a single navbar (that could still be docked up or down). Counterpoint: not much that I could think of, aside from the need to unfurl it again when done previewing.

So if you want to see the results, the modal gets out of the way and you can see the page clearly, then unroll it again. Thoughts? This is potentially better than a new tab altogether, since at that point we aren't operating on the same window context and it becomes necessarily more complex.

Alternatively, people could just close the modal entirely.

[aclist]

Also, (in case it wasn't obvious) the main reason I suggest full screen, fixed height is because it's disorienting to have the modalContent element jump around in size when the content is a different length.

[aclist]

I tried setting .megamod-settings-modal-content to height: 100% and grid-template-rows: 0.2fr and it seems to look pretty good in fullscreen and gives much more room to work with! I don't think this is responsive, though, so the main grid items might occlude the header depending on the resolution. Might be good to put the sidebar, body, and helpbox into their own div that stays below the header line. For that matter, I don't think any of the design is very responsive for mobile right now.

[artillect]

I think I should be able to make the UI pretty responsive with some media queries that rearrange the grid template areas. I'm thinking, in "mobile" mode, it should just go header, sidebar, body, helpbox from top to bottom. Super simple change and I think it should look pretty good. Maybe adding a button to collapse the sidebar on mobile could be nice too.

On the topic of responsive design, I think we should put the modal contents in another container with a max-width of 1360px (the same as the kbin-container class, or maybe a bit bigger since we're using a 3 column design). It feels a bit too wide even at 1080p

[aclist]

Alright, sounds good, let's see what you come up with. I just added keybindings (ctrl-shift-l and esc) to open and close the modal. No rhyme or reasons to the keybinding name, it was just an available key that wasn't already mapped to something.