I've bookmarked and linked this elsewhere on these forums, but given the Blizzard Boards propensity for eating old threads, I thought I would repost some information from a thread on the official forums that I found helpful:
(RE: "I think a lot of authors would benefit from the ability to visually dissect the UI to determine which pieces to align with or to modify...")
Well, an understanding of how the UI is rendered would help:
There are several strata that a frame goes into, e.g. background, normal, dialog, tooltip. A strata simply means that all frames in one strata will be rendered above frames in a lower strata, and below frames in a higher strata.
Within a strata, each frame has a frame level, which determines the order in which it is rendered. The optimal layout is to have all frames in the same strata at the same frame level, since they can be batched and rendered at the same time. When a "toplevel" frame is clicked on, it is raised above other frames in the strata.
Within a frame, there are several draw layers, e.g. background, artwork, overlay, which can contain textures and fontstrings. Within a single draw layer, textures are rendered first, and then fontstrings are rendered afterwards, so text always shows above textures within a single draw layer. Other than that, there is no defined render order, so if you have two overlapping textures in the same draw layer, you never know which will overlap the other.
Only frames can get mouse events, and then only if they have mouse event handlers or are frame types which are clickable (buttons). The mouse focus goes to the frame which is registered for mouse events with the highest strata and the highest frame level under the cursor.
I hope that helps!
(RE: "Out of interest, do named frames with name collisions all end up available to the scripting system (They do all seem to get created, but obviously through the current API you can only 'reach' one of them)")
Yes, they exist, and they get events, but only the first frame actually is added to the global environment by name.
Only named frames/textures/fontstrings are added to the scripting system to save memory, since each object requires a table allocation.
(RE: "I'm curious now. If you have a named frame A with an unnamed child B which has a named child C, and you call C:GetParent(), what do you get back? Does it return A? That seems weird since it's not the actual parent...")
I'm tempted to add all frames (not textures or fontstrings) to the scripting system, since most of them have a name already, and returning nil for C:GetParent() in the example above is obviously not very helpful.
Okay, this will be in the 1.6 content patch. It shouldn't affect anyone much, but it does mean that you don't need to name your frame to get events, and you can call frame:GetParent():GetParent(); and have it work with an anonymous parent.
( Slouken is a Blizzard dev that appears to be the primary community liason for all things UI on the original forums. )