These are two (relatively minor) display issues related to reviewing edits:

Tag Details Flyout

First, below you will see the tag mouseover details block "hiding" behind the overlay. Obviously, a display bug or oversight.

To reproduce: I got to this by clicking on the edit(0) link under a question when a user without edit privileges suggested an edit.

tag details box behind description overlay


Edited Text Change Hidden Behind Reject Reason Overlay

Second, this is less a "bug" than a conflict of the display of overlays.

Essentially, while rejecting an edit, if you're trying to review the edit itself, it may (often does) fall almost entirely behind the overlay, meaning if you need to refer back to the edit changes for your reasoning, you have to close the overlay, review, then reopen it. More annoying than anything. Not real sure how it could be resolved cleanly without changing the UI behavior.

To reproduce: I got to this after reviewing an edit(0) under the question and then clicking on the Reject button on that edit. (Note, I ended up improving the edit in the end.)

* Note: I've added a Feature Request tag for this, since I think this is a side-effect of the design of SOs user interface that I think could be improved. Let me know in the comments if you believe this should be separated into another question.

edit contents for review is directly behind overlay


  • Screens are not infinitely large, so I'm not sure how this problem can be solved. – Cody Gray Mar 12 '12 at 8:11
  • @CodyGray - Here's a stab at it: Allow the user to briefly bring the background modal in front of the foreground without requiring the foreground modal be closed. Demo: jsfiddle.net/yth8s – Jared Farrish Mar 13 '12 at 0:37
  • Ah, I like that idea. In fact, that's super cool! (It's easier for me when I have an idea of what the finished product would look like!) Would it be possible to toggle between both of them by simply clicking on the unfocused one? You know, like all operating systems have allowed us to do for years? It took me a few seconds to figure out that I needed to click a button, and that doesn't really provide as much user affordance even once I figure it out. – Cody Gray Mar 13 '12 at 4:08
  • This I believe is what you are describing: Focus and unfocus background modal on current foreground element click. However, I think that may defeat users who are trying to copy something from that modal, or users who accidentally click it. I'm a bit partial to timing the unfocus event with a golly-gee fade effect thrown in, but that's a bit fancy and diverges a little bit from SOs current UI heuristics. – Jared Farrish Mar 13 '12 at 9:43

You must log in to answer this question.

Browse other questions tagged .