Category Archives: CSS

Cascading Style Sheets

WWW2005 – shameful name dropping

I attended WWW2005 in Chiba, Japan, just outside of Tokyo. It was a fun conference. I met lots of great people, and saw some people I hadn’t in a while. I was pleased to meet, and not drool on, Eric Meyer, who is both taller and cuter than I had imagined.

I also really enjoyed geeking with Bert about developments in WYSIWYG css and html editing. I think I will give stylemaster another try as he said it now has built in templates for different column layouts that have already been tested for browser compatibility. I had been using Inknoise‘s layout-o-matic, and sometimes the list-o-matic at accessify as jumping off points, but it could be nice to have that functionality on the desktop.

I am also thinking of doing a marketing promotion / good deed at dovetail. Yes, they can be one and the same! I would like to develop a basic accessibility report which can be prepared relatively quickly, and yet provide information for decision makers about how their website fairs against S.508 guidelines and WAI checkpoints. I think I will ask, the very energetic, Molly for her advice when I have a basic template put together. Meeting her in Chiba was really fun, she is totally committed to standards and she really knows her stuff.

I saw Tantek, but hardly got to talk to him this time. I also met the newest Internationalization staffer at the w3c, Felix, who, along with Richard Ashida, helped me order “women’s saki” and thus grow to appreciate what had before tasted like the smell of rubbing alcohol.

Of course, I also hung out with Eric and tried to solve the css problems in one of his presentations in the two minutes before he started to speak. He wanted a double row of list items so that they would fit on the projector without scrolling. Much like the A List Apart article that caused readers to get so nasty.

Wendy and I went shopping just before her flight and didn’t discuss accessibility even once. It was lovely to reconnect with her. I hope that Hugo, Vishal, and I can visit with them sometime soon. We bought beautiful pieces of antique kimono silk. Now I will have to find a backing or frame for it. I should have bought something in Japan, their aesthetic is really compelling.

I also met Shawn’s very jetlagged husband who is a pilot and not a geek, so I doubt very much that he has a website. He and Eric geeked about helicopters and plane crashes. Hugo probably would have loved that discussion!

I also saw Zac again from @semantics who had graciously hosted SPARQL-ing days, in Monte San Savino, Tuscany. (Quite possibly the best food ever served at a conference). Libby was also around. Robin turned me on to a traiteur italien on the rue St. Maur, in Paris. I still have yet to check it out because I am studying for my exam.

Ok, thats enough for my first-ever-name-dropping post. If it gets to be a habit I will create a category so that those who wish, can avoid this type of post.

Morgan and the Expanding Container Element

I am working on a site for Mason where he can record his adventures rebuilding a Morgan with his father-in-law. The design is going alright, and I have only two gripes.

  1. First, IE, of course it begins with IE, expands container elements to fit floated content. So the car, rather than bursting from the title bar in a flash of red, sits squarely inside an enormous header. I have found reference to this (the expanding box trick) on Position is Everything, but not how to fix it. I know, I should just get over it and splice the image in two, but I don’t want to!
  2. I don’t love the buttons on the right side. They’ve been changed about a million times, but I still haven’t come up with something that makes me happy.

I don’t really want to use some hack to fix the former. Often they seem to create as many problems as they fix.

WYSIWYG Editor Accessibility Test Results:

Allowing writers to contribute to the creation of accessible documents.


The testing was based on the needs of non-technical content contributors; writers, graphic artists, editors, etc. The program had to shield the user from all the code and provide a simple usable interface.

It is reasonable to expect writers to be able to update documents and follow preexisting styles without substantially compromising accessibility. However, they won’t be able to create or change the overall look and feel of the documents. This type of change requires familiarity with CSS and XHTML, even in the WYSIWYG (What You See Is What You Get) environment. With proper planning, this limitation can actually help insure consistency across large documents.

Determining whether or not a document is accessible is, at best, vague.  Tools for testing accessibility, such as Watchfire’s Bobby, give technical results that must interpreted by someone familiar with Section 508 guidelines and XHTML.  A combination of TIDY, Validation, and Bobby may be appropriate for testing writers deliverables.  Additionally, the writers may need training to understand accessibility issues.  A computer program, no matter how thorough, cannot determine if alt text is appropriate to describe the function or effect of an image.

Five Editorswere able to complete most or all of the tests. Contribute, Dreamweaver, and Amaya produced the most accessible markup. GoLive and FrontPage failed to request alt attributes for images, the most basic accessibility test, and the markup produced by FrontPage [1] didn’t validate.  Three Editors were immediately eliminated.  XStandard did not pass the easy tests.  Authentic and HTML Kit are not WYSIWYG editors.

Amaya’s strengths are that it always produces valid markup and it’s relatively simple user in terface would be easier to learn.  However, it is a quirky program, it crashes often forcing one to save work frequently, and its interface is unpolished and can be frustrating to work with.  It is awkward, and sometimes requires redundant clicking to perform operations.

Contribute, by the same company that makes dreamweaver, is designed as simpler environment from which content contributors can edit documents themselves without risking compromising the accessibility of the mark-up or the overall look of the document. It interfaces with dreamweaver to allow "check-out" of documents and thus protect against accidental overwrites caused when two people try to edit the same document. Contribute and Dreamweaver were the only editors to offer this functionality. Its user interface is a cross between a browser and word processor and most functions are accessed using simple drop down menus. The code it produces is valid and accessible with the exception of alignment of images which would need to be done by administrators using a more complex editor. Administrator preferences must be set to optimize for accessibility.

Dreamweaver MX produced the best markup of all the editors and had nice popup boxes to request accessibility inputs.  It doesn’t, by default, have these options turned on and preferences must be set appropriately when the program is installed.  It also has an internal validator and accessibility checking.  It is more complex, and the set of functions used by the writers would be a relatively small portion of the tools capability, but it does a good job of screening the user from unnecessary complexity and presenting simple dialogue boxes relevant to the current task.  It received 3 1/2 out of four stars in "Supporting Accessible Authoring" according to Constructing Accessible Web Sites by Thatcher et al.

FrontPage’s strength is that it looks almost exactly like MS Word, writers would quickly feel comfortable with the user interface.  However, this is also a danger.  Styling documents in the familiar way would quickly lead to inaccessible code and probably require much more time from a "clean-up" person, who would edit the file directly to eliminate proprietary markup, solve validity errors, and retrofit accessibility features.  It received only 2 1/2 out of four stars in "Supporting Accessible Authoring".

GoLive is a complex program and yet it doesn’t prompt for any accessibility features and uses out of date methods to markup text.  It received only 2 1/2 out of four stars in "Supporting Accessible Authoring".

RoboHelp is not an html editor, it is a program for creating help files like those in typical Windows programs. It supports the creation of smaller documents relating to specific issues and questions as well as Index, Table of Contents, and Search functions. Macromedia states that it outputs professional quality print documents, manages libraries of related help information, and creates s.508 compliant HTML files. A multimedia summary of this program is available at the Macromedia web site. Using RoboHelp to edit existing software users manuals would require rethinking the scope of your project and rewriting a large number of documents.

Editor Accessibility Test Results

  Recommended Possible Runner-ups
  Contribute 2 Dreamweaver MX Amaya RoboHelp
Cost $99.00 $399.00 $0 $999.00
Allows Check-out of documents (protects against accidental overwrites). Yes. Yes. No. Yes.
Interface Screen Shot Screen Shot Screen Shot Client Example
Usability Intuitive, looks like a cross between a browser and a word processor, but produces accessible mark-up.  Has no code view, and simple menu options that allow a writer to participate without knowing HTML.
Also supports "checking out" documents to avoid accidental over writes with multiple contributors. 
Would be inappropriate for technical site developers but interfaces with Dreamweaver MX. [2]
Intuitive, the user is somewhat screened from the power/complexity of the tool and offered options relating to the current task.  Very impressive. [2] This is a quirky program that does generate valid HTML, but its unprofessional user interface can be very frustrating.  Software for creating help systems (similar to clicking on help in windows programs), it creates search, index, table of contents, and can export to print quality documents.
Would require rethinking the project and rewriting existing documents to fit RoboHelp framework.
Reliability Good. Good. Crashes regularly. Not Tested.
Web site Contribute Macromedia – Dreamweaver MX 2004 Amaya RoboHelp
Easy Tests        
move a paragraph using cut/paste Yes. Yes. Yes.
No right click, forced to use menus.  Clean but left a stray <p>.
insert <p> Yes. Must press return twice or it adds style=margin-top: 0; this can be fixed with administrator options. Yes. Yes.  
move image Yes. Yes. Can cut but not paste.  Requires reinserting  
find and replace product name Yes. Yes. Yes.
Edit: Find
change section of font to bold Yes.
Excellent, used <strong>.
Excellent, used <strong>.
Used <span>.
add link Yes. Yes.  Yes, but convoluted.  Highlight text: Click Link button: Enter URI and alt: Click confirm: Click on text again.  
Medium Tests        
insert "note" paragraph Yes, easy drop down menu. Style must already exist, cannot be created in Contribute. Yes. Yes. 
Style: Apply Class: Note
insert image inline and floated Inline – Yes.
Float – No, uses option of align="right", which is deprecated.
Inline – Yes*.
Float – Yes.* apply style from the properties menu.
Inline – Yes,
Float – Yes, apply style.
insert table Yes, prompts for header but not caption or summary. Options are limited, preserving simple interface. Yes, very good. Prompts for header, caption, and summary. Not fully 508 compliant but valid  
Hard Test        
increase font for all headings No. Yes.
Right click: Manage Styles: new:  h2: tag
Requires  knowledge of CSS.
"Create rule" doesn’t work.  Can edit existing rule.
Requires  knowledge of CSS.
Create Index No.
(Plan: Use CSS and style sheets to generate automatically)
(Plan: Use CSS and style sheets to generate automatically)
No. Yes.
Create Table of Contents No.
(Plan: Use style sheets to generate automatically)
(Plan: Use style sheets to generate automatically)
No. Yes.
TIDY the document Yes.* Yes.* No.
Warning: table lacks summary attribute.
Validate XHTML Valid.* Valid.*
Excellent, can be validated within the program against different doc type declarations. Also, advanced CSS error checking, browser compatibility verification, and accessibility flags.
Validate 508 Compliance Using Bobby Yes.* Yes.* Table missing  row and column headers.  

Not Reccommended

The following Editors are not reccommended either because they failed to create accessibile mark-up or they were inappropriate to the task.  Specific details of each editor are below, but several of the tests were not completed if the browser failed earlier easier tests.

  Functional But Not Accessible Inappropriate
  Frontpage GoLive Authentic XStandard HTML Kit
Cost $199.00
+ $299 for LIFT software to enable FP to produce accessible code.
$399.00 $0 $0 $0
Allows Check-out of documents (protects against accidental overwrites). No. No. No. No. No.
Interface Screen Shot Screen Shot Screen Shot Screen Shot Screen Shot
Usability Looks like a word processor, but dangerous because familiar methods produce invalid, proprietary, and inaccessible mark-up.  Requires expensive accessibility add-ons.
*Tested without LIFT or AccVerify.
Fairly Complex.  Some operations awkwardly required drag and drop, others, menus an inexperienced user might never notice. Very Complex.  Not appropriate to the task. Not at all obvious how to complete even simple tasks. Not WYSIWYG.
Reliability Good. Good.   Crashed OS and never managed to save.  
Web site Microsoft FrontPage
 UsableNet – LIFT for FrontPage
Adobe GoLive Authentic 2004 – XML Document Editor XStandard FREEWARE / SHAREWARE XHTML 1.1 WYSIWYG EDITOR HTML-Kit
Easy Tests          
move a paragraph using cut/paste Yes, though it inserted a "&nbsp;" Yes, left a stray <p>. No. No.[3]  
insert <p> Yes. Yes. No. No.[3]  
move image Yes. Yes. No. No.[3]  
find and replace product name Yes, but deleted a space after the name. Yes. No. No.[3]  
change section of font to bold Yes, but used <b>, a nonstructural tag. Yes, but used <b>, a nonstructural tag. No. No.[3]  
add link Yes. Yes.  Done in separate window. No. No.[3]  
Medium Tests          
insert "note" paragraph No. Yes. Right Click: CSS Style: Note.      
insert image inline and floated Inline – Yes, but doesn’t prompt for alt text.
Float – No, it offers the option of align="right", which is deprecated.
Inline – Yes.
Float – Yes, apply style, but doesn’t prompt for alt text.
insert table Not fully 508 compliant, it doesn’t prompt for important info. Not fully 508 compliant, it doesn’t prompt for important info.      
Hard Test          
increase font for all headings Yes.
Format: Style: HTML tags: h3: Modify.
Requires knowledge of CSS.
While technically possible, the software is complex enough that after 5-10 minutes the task wasn’t finished.      
Create Index No. No.      
Create Table of Contents No. No.      
TIDY the document No.
Warning: <img> missing alt attribute, <img> not closed, table lacks summary attribute, proprietary code.
Warning: table lacks summary attribute.
Validate XHTML Not Valid.
<img> missing alt attribute, <img> not closed, table lacks summary, proprietary code.
Validate 508 Compliance Using Bobby Table missing row and column headers, <img> missing alt attribute. Table missing row and column headers.      

Screen Shots


  1. Frontpage was tested without the optional LIFT software from UseableNet that allows it to produce accessible code. UseableNet did not respond to demo requests .
  2. Preferences must be optimized for accessibility by site administrator.
  3. Crashing and instability limited the scope of the testing.

Web Design Resources

I became a geek by accident. I was a groupie for ages and then it just kind of rubbed off on me. I am eager to collect my links before they get lost.  The resources for learning to design well are out there, but hard to find and evaluate until you know the basics.  This represents, quite simply, what I know so far. Designing to standards is so graceful when you finally feel comfortable with it, it demands a lot, but now I wouldn’t do it any other way.

Almost all of the pages I write are XHTML 1.0 Strict, with valid CSS.  Support for it is excellent now, and with some thought no one, not even users of Netscape 4.X need to lose content.  They may not get to see your gorgeous design, but your page will be light and flexible, and users of modern browsers can still get a full user experience without designing different sites for every browser ever made. 



Web Standards

I started by reading the specifications at the W3C.  I like this approach, but there are probably easier ways to go about it.  The specifications are usually relatively straightforward, but they include a lot of information about browser implimentation that isn’t strictly necessary.  Also, they just aren’t targeted to designers.  They aren’t supposed to be.  I am ordering Eric Meyers book about CSS and I will let you know what I think. 

Design Resources

  • Color Scheme – A tool for harmonizing your color scheme.
  • ChromoFlash – another color tool (in French).
  • A list Apart – Articles on all aspects of standards based design.
  • Spazowham – I am completely in awe of these people, they are incredibly clever and committed to accessibility.  No sacrifice.
  • Layout-o-matic – For basic layout choices you do not need to reinvent the wheel.
  • Essential Fonts For Designers – A source for free true type fonts.
  • Dreamweaver – An excellent tool, though it needs to be coerced into producing valid accessible code.
  • XMLSPY – This editor is amazing, valid or very nearly valid code 100% of the time.  Not for the faint hearted, this is a powerful tool, not a WYSIWYG environment.

Cross Browser Compatibility

  • Position is Everything – Excellent source of information on css bugs and support. Use caution employing their techniques, some of the cures are worse than the disease. I would rather add a couple unstructural div tags than a mess of hacks in the css.


  • Designing Web Usability – by Jakob Nielson, a fabulous book, takes the guess work out of making a website work for the users. I read it in a weekend, it managed to be that engaging.