Right now the QuickView is using a very basic "one size fits all" layout, but allowing images to get a bit taller if necessary is a simple change.

The "frameless" design is also an interesting idea, because accommodating a full-bleed background color is tricky for a number of reasons, and you end up having to do things like override skin-specific body margins and padding for the entire page.

Change 622448 had a related patch set uploaded (by Anne Tomasevich; owner: Anne Tomasevich):
[mediawiki/extensions/WikibaseMediaInfo@master] Update QuickView layout

https://gerrit.wikimedia.org/r/622448

@mwilliams I'm reviewing this patch since Anne is out this week. One thing that is a little different from your original mock-ups is that we now have a light grey bar at the top of (some, eventually all) tabs that is then separated from the quickview background by a small gap. The background color for both is very subtle.

Let me know if this still looks good to you and I'll get this merged shortly.

@egardner Yeah, the background is very subtle both cases, chatted with Anne about this but I was feeling like the next step up in our gray's made it feel muddy / almost too noticeable. My plan was to let it slide for this release / alpha, start to use it more and then make any small color iterations as needed for beta.

@mwilliams one more layout / design question for you.

The updated Quickview layout now lets images get taller (the original design limited them to a fixed height). It might still be a good idea to set a max-height for the Quickview image, because otherwise portrait-orientation images have the potential to become really huge.

Without max-height:

With max-height of 400 pixels (arbitrary value):

Adding a max height makes it less likely that portrait images will push the details down outside of the viewport, at the expense of creating a lot of empty space to either side of the image. If we decide to go this route, is it worth introducing a new (darker) background color here?

Let me know what you think and I can finalize things here.

@egardner Good call out! I have been trying not to be too afraid of letting users scroll down in the quick view and Ramsey had mentioned that a majority of our images are landscape.

That being said, I think there is probably a middle ground here where we should always attempt to show more of the text below in order to make it super obvious that you can scroll. For example, it looks like our friend Google Images, keeps a max-height of around 85% to always allow at least two lines of the description when the photo is super tall / portrait no matter the viewport size. Is something like that possible for us?

I would avoid adding a new background color for now, since that's what we were trying to get away from in the previous iteration, and just see how it floats on the current (albeit subtle) color.

Example of the quick view on Google with different viewport sizes

We have a lot of other UI chrome taking up vertical space on the page, but setting a max-height of 50vh (50% of the user's viewport height) seems to accomplish what you're describing. My only other concern here is that the "x" button becomes a bit hard to see when it sits on top of the grey background (which happens when the image is narrow). But this could be refined in a follow-up patch if necessary.

Chatted with Eric about this. We are going to try 60vh for now and see if there are any updates to the X button styling in a future patch.

I also agree with Eric that the UI at the top of the page, before the results, is creating some weirdness with how quick view works and scrolls and created a new ticket with a possible solution here: https://phabricator.wikimedia.org/T261687

Change 622448 merged by jenkins-bot:
[mediawiki/extensions/WikibaseMediaInfo@master] Update QuickView layout

https://gerrit.wikimedia.org/r/622448

This patch has been merged but I'm not sure when it will go out to production (the train is not running this week due to the data center switch).

Works on production.