1 | 2 | 3 | 4 | 5

6 - 10   [22]

WCAG Working Draft Updates

Also relates to Web Standards and Accessibility

New Working Drafts of WCAG 2.0 and accompanying HTML and CSS techniques have recently been published:

Posted on Aug 03, 2004 at 21:16:59. [Comments for WCAG Working Draft Updates- 0]

Experiments With DHTML Tooltips

Also relates to DOM Scripting

Just been having a little play with alpha transparencies and event handling for customised tool tips using DHTML and CSS. Just another reason why Internet Exploder should be laid to rest!

So, here is the first run at accessible DHTML transparency tool tips. There is more to develop to make this accessible to the widest possible audience, so will hopefully come back to it at the turn of the tide

Posted on Jul 11, 2004 at 05:29:06. [Comments for Experiments With DHTML Tooltips- 0]

CSS Negative Margins Algebra

Also relates to Accessibility

Defining CSS layouts with negative margins requires a high level of precision to ensure that all siblings are cleared effectively. Pie-fecta was the earliest example of this technique, demonstrating a complex set of dependant CSS rules. But, this should not make the technique so daunting that it is ignored. Ryan Brill's recent publication provides an insight into the simpler side of the technique. Only glimpsed at in his article, negative margins offer one huge benefit that should put table-based design to rest once and for all - flexible document structure.

As a scenario take the following document structure that defines the main content areas for a three column layout:

<div id="center">  </div>
<div id="left">    </div>
<div id="right">   </div>

Since the central column contains the main content, I have chosen to lead with it in the document structure for accessibility and SEO. The left column contains the navigation menu, and the right column a subsidiary menu/content (or perhaps advertising). Deeper into the site hierarchy, I decide to utilise the right column to bind additional information to the central column (eg links to related articles, or recent material). However, the document structure will now be detached since the main navigation (in the left column) separates the two bound columns. While this is of little relevance on a styled page where the columns are always in the same position, it is counter-intuitive for assitive devices or an intelligent search bot, where the style rules do not apply. The solution is to flip the left and right columns in the document tree. And the good news is with negative margins this can be achieved without changing a single rule in the underlying CSS!

So now it is time for the mathematics. I started this entry by emphasising the importance of precision, and there is no better way to ensure this than some CSS algebra.

α = column 1 width (#middle)
β = column 2 width (#left)
γ = column 3 width (#right)

Δ = predefined balancing unit

#middle {
  margin:0 [-(α+(β-Δ))] 0 β;

#left {
  margin:0 0 0 -Δ;

#right {

The middle column is given a negative right margin to the value of its own width (α) plus the left margin (β) less a predefined unit (Δ). This provides the entire width of the parent container less one unit on the left for the middle column's siblings. The left column is floated with a negative left margin to the value of the predefined unit to place it flush left to the parent. The right column is simply floated right. The predefined unit is arbitrary, but obviously should be less than the width of the left column - I generally use a unit of 1 (eg 1em, 1px, 1%). The underlying premise behind this principle is explained in the CSS2 Specification.

A float can overlap other boxes in the normal flow (e.g. when a normal flow box next to a float has negative margins) Visual Formatting Model, CSS2 Specification

Now, the right and left column can be reversed in the document tree without any need for additional rules or any detrimental affect on the presentation. A clearing element will apply to all three columns - allowing any column to be longest (resolving the inherent problem with absolute positioning).

Here are a few examples:

These examples have been tested across all the major PC browsers, but I have not had an opportunity (or time) to test them on Mac and Linux. The only major bug arises in IE6 for a contained liquid width (ironically not IE5.x). There is also a gotcha involving preformatted text in the IE browsers for both liquid and fixed widths (explained in the above examples). The only hack required accounts for the IE Doubled Float-Margin Bug by declaring the containers' display inline.

Any layout containing floats has potential for browsers discrepancies (eg Peekaboo bug and IE Float Margin as above) and potential self-destruction. So far on quite complex test examples I have found this technique to work adequately cross browser. Plus, in theory the technique can also be applied to sub-containers - so long as the formula is balanced the columns can be cleared.

As for colouring the columns, the Faux Columnstechnique or a similar set of containing wrappers is required. IMHO, such non-semantic containers should be avoided in the document. This can be resolved by utilising presentational javascript. The presentation should first be made accessible to users with no javascript, then an onload event handler can be attached to the window object which performs the wrapping. Here is a little example, which I intend to write up soon - the Elastic Fantastic.

Posted on Jul 01, 2004 at 01:59:57. [Comments for CSS Negative Margins Algebra- 1]

CSS Slide And Zoom

Also relates to Accessibility

Since first discussing CSS Zoom as an alternative technique for accessible design earlier in the year, it has become an integral part of my design methodology. While this technique does come with disadvantages, especially related to images, I like the ability to enlarge an entire page to very high screen resolutions and similarly shrink the page to display satisfactorily in 640 x 480 dpi, without the worry of text or form fields breaking their parent containers.

In the latest incarnation of the Still Stoked website I have juxtaposed CSS Zoom with Doug Bowman's Sliding Doors technique to de-table-ise the three column design. The new layout relies on an extended banner graphic at the top of the page that can slide in out as the page is resized without affecting the look and feel of the page, while all the internal columns and text can grow and shrink freely. Enhanced accessibility and improved SEO were also high priorities for the site, so absolute positioning is implemented on the menu and side columns to allow the actual page content to appear first in the document structure.

The only complication that arose was incorporating a fixed width on the right hand column to ensure the background graphics remained locked together. A wrapper container is used to declare borders to house the left and right columns, where the left column is relative and, as just stated, the right column is fixed. But since the wrapper element contains floating elements (the internal columns) it must also have a width declaration. The problem is clear - how to combine a relative width and fixed border within the CSS Box Model.

The solution was to balance out the fixed width border of the wrapper container with a padding in its parent container as follows:

#cont {
	/* [..snip..] */
#wrap {
	border:1px solid #83acd6;
	border-width:0 99px 0 8em;
	margin:0 -99px 1px 0;

So the relative components of #wrap (left border and width) balances out the width of #cont, while a right padding in #cont creates space for the fixed width right border in #wrap. For FireFox, Mozilla and Opera that seems to be job done, but the additional negative right margin is required on IE6. Not too much of a challenge! But of course playing with the Box Model always heralds danger when our least favourite family of browsers are booted up!

As it happens, in this instance, the hack required to appease the IE5.x family is simple - just declare the same width for both #cont and #wrap. After all, this solution is simply a case of balancing the equations and for these legacy browsers borders and padding are declared internally to the width of the container. So if the containers have the same width the browsers should be happy. I like to keep legacy hacks as far away from the main CSS file as possible, so these equal width declarations were placed in a file called using the mid pass filter (along with a few other Lost Child hacks for IE5.0).

This implementation of the CSS Slide and Zoom technique seems to work effectively across the entire range of PC browsers, and ICapture gave positive feedback for Safari. Please let me know in the comments of any glitches are observed on other browsers (IE5 for Mac perhaps?).

Posted on May 09, 2004 at 15:53:29. [Comments for CSS Slide And Zoom- 0]

CSS Zoom Factor

Also relates to Accessibility

Recently I have been considering the CSS Zoom Factor (or Full Page Zoom) as a very viable option for controlling the size of the root container in a design layout. There are several examples of this technique on the CSS Wiki, and it has already produced extensive discussion on Simon Willison's Blog but it does not seem to have been widely adopted as an alternative to fixed width or percentages yet.

In short, CSS Zoom declares the root container dimensions in a unit relative to the font size (em). This allows the whole page to scale up and down when font-size is adjusted. The new design of my business (and blog) site utilise this method. I actually stumbled on it by chance initially - one of those trial and error situations - but as the design developed, it became clear that this method resolved a number of limitations of fixed dimensions and percentage dimensions:

  1. Text breaking out of columns above several levels of magnification.
  2. Resolution limitations - fixed dimension columnar designs can become squashed and barely legible at super high resolutions with several magnifications of zoom. Percentage dimension designs will resize to the resolution, but they suffer the same problem at a single resolution when font is increased extensively. Similar problems can arise when down sizing resolution and font-size.
  3. Precise positioning can easily be broken in fixed and percentage dimensions. A typical example I have experienced several times is the absolute placement of a horizontal navigation bar. As font size increases the content may fold over to two lines, hence breaking the synchronisation of following content..

CSS Zoom also has disadvantages:

  1. Images do not resize with the text (except Opera's internal zoom mechanism), so blank spaces will soon appear where the design is image specific.
  2. Nesting fixed width elements (eg floated elements) inside the relative parent can become impossible.
  3. If a user is re sizing the font to a very large size at a small resolution, much of the page is going to be forced out of the viewable area requiring horizontal scrolling.

I think the last point mentioned above is a major issue. There are likely to be two groups of users who resize fonts - those with extra large screen resolutions and those with poor visibility. The application of CSS Zoom is ideal for the first group but forcing an impaired user to scroll horizontally impinges negatively on the accessibility of a page. Arguably, many fixed width/percentage width designs can become quite illegible at extra large font-sizes anyway (3 to 4 times zoom), while the Zoom factor will still maintain its form. Also with careful design planning, a columnar layout can allow a single column to display clearly within the viewable area at high resolutions.

The three column layout displayed on Severn Solutions has been designed to take this into account. As an example, the home page can be resized in Firebird to five times magnification at 1024 by 768 screen resolution and allow each column to be read clearly with only vertical scrolling, once it has been screen centred. While the larger blog column layout can be resized to three times magnification without the need for horizontal scroll.

UPDATE - 2004-02-10. Recent testing has shown that a centre-aligned root container in the document body must have a border declared to prevent the container from disappearing off the left edge of the screen as the font is increased.

Posted on Feb 08, 2004 at 04:29:35. [Comments for CSS Zoom Factor- 0]

Breadcrumbs Trail

[ Home ] -> TW Blog -> CSS Design
Site Map

The Severn Solutions website achieves the following standards:

[ XHTML 1.0 ] [ CSS 2 ] [ WAI AA ] [ Bobby AA ]

Page compiled in 0.007 seconds