It's possible to tab out of a modal. This could possibly be fixed by detecting bubbling focus events anywhere on the BODY, and checking the event target. If the target's outside of the modal, focus the first focusable element in the modal (or its first button).

The code to remove the modal fade should check if multiple modals are opened. Alternatively, the SEN.GUI.Dialogs._Dialog constructor can simply prevent the creation of a second modal.

The size of the SCII tab's clickable area is a result of my (successful :3) quest to achieve near-perfectly-semantic markup in the header. At the time, I figured no one would notice it.

The Opera bug is just that: an Opera bug. I've analyzed it and can prove that it's a browser bug, not bad code. Since there's no way (legitimate or CSS-hack-based) to target CSS specifically for Opera, I cannot fix it without breaking it in every single other browser. I've filed a bug with Opera using their website, providing them with a description of the problem and a link to the affected page (SEN's Forum Index). Hopefully, they'll fix the bug soon, because there's nothing I can do on my end.

The Shoutbox "Extras" button is styled differently because it is "fake": it's an A rather than an INPUT[type=button]. I'll need to write specific CSS for it; no biggie.

For accessibility purposes, the "Search" text in the quicksearch should be changed into a LABEL and shown over the textfield when the textfield is empty. This can be done with CSS and JS, and it can be made to degrade gracefully.

CSS can control the placement of an element.

position: static
This is normal positioning for elements. Setting their coordinates (using "left", "top", "bottom", and/or "right") has no effect.

position: relative
You can shift an element from its normal position by setting coordinates. It will not displace other objects if moved in such a manner; it will overlap them, and usually display over them.

position: absolute
The element is positioned absolutely by its coordinates, and does not affect the placement of other elements. In many cases, it is positioned relative to the document. It will usually display on top of anything it overlaps.

position: fixed
The element is positioned absolutely by its coordinates, and does not affect the placement of other elements. It is always positioned relative to the window, such that it scrolls with the window. It will usually display on top of anything it overlaps.

Mobile Safari is interpreting "position: fixed" as "position: absolute". If I say "position:fixed;left:0;top:0", that puts an object in the top-left corner of the screen. If I say "position:absolute;left:0;top:0", that puts an object in the top-left corner of the page. Mobile Safari, then, is putting the modal at the top of the page instead of the screen, which is what it should be doing.

It's possible to tab out of a modal. This could possibly be fixed by detecting bubbling focus events anywhere on the BODY, and checking the event target. If the target's outside of the modal, focus the first focusable element in the modal (or its first button). Could be problematic, though, as IIRC focus events actually don't bubble at all.

The code to remove the modal fade should check if multiple modals are opened. Alternatively, the SEN.GUI.Dialogs._Dialog constructor can simply prevent the creation of a second modal.

The size of the SCII tab's clickable area is a result of my (successful :3) quest to achieve near-perfectly-semantic markup in the header. At the time, I figured no one would notice it.

The Opera bug is just that: an Opera bug. I've analyzed it and can prove that it's a browser bug, not bad code. Since there's no way (legitimate or CSS-hack-based) to target CSS specifically for Opera, I cannot fix it without breaking it in every single other browser. I've filed a bug with Opera using their website, providing them with a description of the problem and a link to the affected page (SEN's Forum Index). Hopefully, they'll fix the bug soon, because there's nothing I can do on my end.

The Shoutbox "Extras" button is styled differently because it is "fake": it's an A rather than an INPUT[type=button]. I'll need to write specific CSS for it; no biggie.

For accessibility purposes, the "Search" text in the quicksearch should be changed into a LABEL and shown over the textfield when the textfield is empty and unfocused. This can be done with CSS and JS, and it can be made to degrade gracefully.

For the bug regarding the depths of multiple modeless dialogs... Say you open four draggable modeless dialogs in order, and we'll call them A, B, C, and D.

Drag C so that it overlaps D, and focus C.
Drag B so that it overlaps C, and focus B.

The expected result is that B is in front of C and C is in front of D, but what actually happens is that B and C are in front of B. This is because C and D now have the same (unfocused) z-index and are hence being displayed in source order; D comes later in the code (having been created later), and hence shows over C.

Drag A so that it overlaps B, and focus A.

Now we see the full problem. A is in front of all dialogs. D is in front of C, and C is in front of B. Again: B, C, and D are being displayed in source order.

The only fix that I can think of would be to manually set the z-indices for each modeless dialog, but this is messy and not adjustable with CSS... I wonder if there's another way...