Setting up Overlays

The Overlay Control is an extension of Module; its role is to facilitate the creation of modular content that is absolutely positioned above the flow of a page. It adds additional functionality to Module, including methods for positioning, multiple custom events for monitoring internal property changes, and a built-in <iframe> solution for dealing with <select> element bleed-through in Internet Explorer.

Overlay is fundamentally a building block for other UI controls. The concepts presented in this example will form the basis for the way that you interact with all of its subclasses, including Panel and Dialog.

In this tutorial we will build three Overlays with different types of positioning. One of them will be based on existing markup; the other two will be created dynamically using script. In addition to instantiating the Overlays, we will also use the constructor to pass configuration properties for each of our Overlays.

These Overlays introduce a few of the configuration properties which are available to help position the Overlay.

• Centered In The Viewport

  The fixedcenter property, when set to true, will force the Overlay to always be positioned in the center of the viewport — even when the window is scrolled or resized. The visible property determines whether the Overlay should be visible, and the width property allows a CSS width to be set for the Overlay.

• At A Specific Page Co-ordinate

  Basic pixel-based positioning is available via the xy property, which can also be split into separate properties (x and y). The xy co-ordinates are page co-cordinates, relative to the top/left corner of the document.

• Aligned To An Existing Element On The Page

  The context property, as shown in overlay3, takes an array of values. The first entry in the array is the id of the element to which we want to anchor the Overlay. In this case, that element is a <div> with an id of ctx. The next two entries specify the positioning of the Overlay — tl and bl mean, "Anchor my Overlay's top left corner to my context element's bottom left corner." (Other possible values include tr and br for "top right" and "bottom right", respectively.). These first three entries in the array are required entries.

  The fourth entry in the array is optional and specifies the list of events (triggers) for which we want to re-align the Overlay with the context element. If this fourth "triggers" entry is not specified, context alignement is only done once, when the Overlay is created. This is sufficient for a majority of use cases, where the page co-ordinates of the context element remain constant. However in fluid layouts (such as this example template), the page co-ordinates of the context element change as the window is resized, therefore we ask the Overlay to align itself whenever the "beforeShow" and "windowResize" events are fired. The API documentation for the context configuration property discusses the events which are supported in more detail.

In the next step, we will define CSS styles that allow us to see a clear visual representation of our Overlays; remember, Overlays are building blocks for other controls and as such they are not styled by default. We will also style our ctx context element so that it's easy to see:

The markup for overlay1, plus the context element ctx and the buttons to show all our Overlays, is displayed below. Note that overlay1 has an inline style of visibility:hidden set in advance. Most browsers are slower to render CSS than inline styles, and we want this marked-up Overlay to be hidden by default. If the inline style isn't present, it may cause a brief "flash of unstyled content" where the Overlay may be visible on slower machines.