dbx manual

2. Writing the CSS framework

Now we have an HTML structure with the relevant class names, the next thing to do is apply the styling.

Remember as you go that the default CSS rules apply to all browsers, not just those that support the script. But not all rules apply by default — some are dynamic with state and script support, and we'll talk about those as they arise.

Core CSS

We begin with a core set of styles that must be included, which you must not neglect or override with other styles, or the script may not work at all.

There are also some strongly-recommended style restrictions, which you should avoid undermining for the sake of cross-browser stability:

/****************************************************************
  docking boxes core CSS: YOU MUST NOT CHANGE OR OVERRIDE THESE 
*****************************************************************/
.dbx-clone 
{
    position:absolute;
    visibility:hidden;
}
.dbx-clone, .dbx-clone .dbx-handle-cursor 
{
    cursor:move !important;
}
.dbx-dummy 
{
    display:block;
    width:0;
    height:0;
    overflow:hidden;
    margin:0 !important;
    padding:0 !important;
}
.dbx-group, .dbx-box, .dbx-handle 
{
    position:relative;
    display:block;
}

/****************************************************************
  DO NOT ADD padding, margins or borders to dbx-box, 
  to avoid layout discrepancies between it and the clone.  
  dbx-box is best left as visually unstyled as possible 
  (instead, have another element inside the box, and style that)
*****************************************************************/
.dbx-box 
{
    margin:0;
    padding:0;
    border:none;
}

/****************************************************************
  otherwise, do what you like :) 
*****************************************************************/

The restrictions are there to suppress the style properties most likely to cause problems for the script — position or size discrepancies between the static and dragable elements, rendering bugs or similar instabilities.

I've identified this, and two other specific problem areas:

padding, margins or borders on the boxes ("dbx-box" elements)
These properties can result in a whole range of positioning and sizing differences between the static and dragable elements, in all supported browsers. I generally recommend that you keep the boxes themselves as visually unstyled as possible, and instead use the elements inside them as design hooks.
margin-bottom on the handles ("dbx-handle" elements)
If the handles have margin-bottom, it could give rise to an odd rendering quirk in Firefox and other mozilla browsers, that can make the static elements shift position slightly when dragging occurs near them, or snap into place offset from their correct position (by the same amount as the margin)

Custom CSS

We've already seen the main behavioral class names: "dbx-group", "dbx-box", "dbx-handle" and "dbx-content". These can be used as design hooks as well, and are supplemented by a range of default and state-dependent class names, giving maximum control over the interface design.

All the available rule-shells are in the "dbx-allrules.css" stylesheet in the download package. Here's a reference of what's available:

Box and content-area states

The dbx-box class name is always present on boxes. The additional box class names apply in addition to that value, not instead.

/* boxes */
.dbx-box 
{
}
	
/* + boxes when open */
.dbx-box-open 
{
}

/* + boxes when closed */
.dbx-box-closed 
{
}

/* + boxes in their focus state 
     [when handle/anchor has the keyboard focus] */
.dbx-box-focus 
{
}

/* + boxes in their hover state  
     [when mouse is over handle/anchor] */
.dbx-box-hover
{
}

/* + boxes in their active state  
     [when mouse or key is down on handle/anchor] */
.dbx-box-active
{
}

/* + target boxes  
     [when identified as a target for swap or insertion, before movement occurs] */
.dbx-box-target 
{
}

Note that the "dbx-box-target" class is incredibly transient during normal movement, since it only applies in the short window of time between a target being selected and the movement actually occurring, a matter of milli-seconds. It exists mainly to ensure backward compatibiliity with dbx2, and has been superceded by the use of dialog classes.

Boxes can also be identifed as ungrabbable, meaning that they can be targets for swap or insertion, but they cannot be grabbed or moved directly. Such boxes have an additional "dbx-nograb" class name.

/* + boxes that cannot be grabbed */
.dbx-nograb
{
}

The show/hide behaviors work by appending the -open or -closed class name to the relevant box, so how it actually comes out is up to you, defined using descendent selectors from those rules. An obvious choice would be to use display:block when the box is open and display:none when it's closed.

/* inner content area */
.dbx-content 
{
}

/* [inner content area when the box is open] */
.dbx-box-open .dbx-content 
{
}

/* [inner content area when the box is closed] */
.dbx-box-closed .dbx-content 
{
}

Handles

The handle class is static (since you add it yourself) and therefore applies to all browsers. But the handle cursor class is added by the script, only if the script is supported.

/* handles */
.dbx-handle 
{
}

/* + handle cursors */
.dbx-handle-cursor 
{
}

The obvious choice for this is to use the "move" cursor, to indicate that the object is draggable:

/* + handle cursors */
.dbx-handle-cursor 
{
    cursor:move;
}

Toggle buttons

Toggle buttons have four possible states: box is open, box is closed, toggle has the focus and box is open, and toggle has the focus and box is closed.

Toggles are either anchors or buttons (depending on the value you set for toggle button element type), and if they're anchors, then for the sake of cross-browser stability you should define each state in its :visited pseudo-class as well.

/* toggle links or buttons */
.dbx-toggle, .dbx-toggle:visited 
{
}
	
/* + open */
.dbx-toggle-open, .dbx-toggle-open:visited 
{
}

/* + closed */
.dbx-toggle-closed, .dbx-toggle-closed:visited 
{
}

/* + open and highlighted */
.dbx-toggle-hilite-open, .dbx-toggle-hilite-open:visited 
{
}

/* + closed and highlighted */
.dbx-toggle-hilite-closed, .dbx-toggle-hilite-closed:visited 
{
}

If you use the CSS Sprites technique, you can create all four button states in a single image, and then selectively show the part you want for each state using background-position. This is what I've done in the main navigation boxes demo:

.dbx-toggle 
{
    display:block;
    width:20px;
    height:20px;
    padding:0;
    margin:0;
    border:none;
    background:url(images/purple-toggle.gif) no-repeat;
    position:absolute;
    top:14px;
    right:3px;
}
	
.dbx-toggle-open 
{
    background-position:0 0;
}

.dbx-toggle-closed 
{
    background-position:0 -20px;
}

.dbx-toggle-hilite-open 
{
    background-position:-20px 0;
}

.dbx-toggle-hilite-closed 
{
    background-position:-20px -20px;
}

The absolute positioning on the toggle places it at the origin of its parent handle, which is relatively-positioned.

Keyboard navigation tooltips

Since browsers don't normally show title attribute tooltips when an element receives the focus, the script implements informational tooltips itself. These are created as a singe <span> element appended to the group container, with the class name "dbx-tooltip":

/* keyboard navigation tooltip */
.dbx-tooltip 
{
}

The tooltips are assumed to have absolute positioning, and positioned by the script to the origin of the box using left and top, so you should not set those values yourself. To control the position of the tooltip relative to the box, use margin values.

The best way to style them visually is using CSS2 System Colors so that they match your end-user's GUI, and this is what I've done in the main main demo. If you're happy with that, there's no need to change it, apart from adjusting the width to suit your average text, and the margin to place it where you want it relative to the box:

/* keyboard navigation tooltip with CSS2 system colors */
.dbx-tooltip 
{
    margin:100px 0 0 0;
    display:block;
    position:absolute;
    width:120px;
    border:1px solid InfoText;
    background:InfoBackground;
    color:InfoText;
    font:small-caption;
    font-weight:normal;
    padding:2px 4px 3px 5px;
    text-align:left;
}

Clones

The clones are duplicates of the boxes, which you see when performing a drag operation or when animation occurs — the real boxes never move, they only re-arrange their node order at the end of each operation.

You can apply additional styles to the clones to give them a slightly varied appearance:

/* + clone styles 
     [a clone is a dbx-box with this additional class] */
.dbx-clone 
{
}

Nothing is really necessary here, but I've used a small amount of opacity just to give them that extra touch of coolness:

/* + clone styles */
.dbx-clone 
{
    opacity:0.8;
    filter:alpha(opacity=80);
}

In addition the the basic clone class, there are two additional classes (applied in addition to "dbx-clone") which indicate what type of clone it is. There's a class for drag-clones (the clone that you're holding when you move boxes with the mouse), and a class for animation clones (the clone that see moving when animation occurs).

/* + additional drag clone styles 
     [a drag clone is a dbx-clone with this additional class] */
.dbx-dragclone 
{
}

/* + additional animation clone styles 
     [a animation clone is a dbx-clone with this additional class] */
.dbx-aniclone 
{
}

There are also clone classes that apply to dialog elements. A dialog is the element that indicates a target for confirm-based orientations, and its class name further indicates whether or not the target is allowed. You can see this in action in the rules demo

/* + additional dialog styles 
     [a dialog is also a clone, but it has no content] */
.dbx-dialog 
{
}

/* + dialog that indicates position is not allowed */
.dbx-dialog-no 
{
}

/* + dialog that indicates position is allowed */
.dbx-dialog-yes 
{
}

Setting up the HTML | Implementing the script

dbx manual

Basic setup:

  1. Setting up the HTML
  2. Writing the CSS framework [this page]
  3. Implementing the script
  4. Accessibility notes

Advanced development:

  1. API events
  2. Remote controls
  3. The rules engine

dbx main page

Categories...

Website gadgets

Bits of site functionality:

Usability widgets

Local network apps

Web-applications for your home or office network:

Game and novelties

Our internal search engine is currently offline, undergoing some configuration changes in preparation for a major site overhaul. In the meantime, you can still search this site using Google Custom Search.


In this area

Main areas


[brothercake] a round peg in a square hole, that still fits