Archive for the ‘css’ Category

IE7 and Firefox 2 : headaches for web developers

December 3, 2006

IE7 and Firefox 2 are now released and begin to spread in the world thanks to auto-updates and the cool factor driving technology.. What does this bring us? Well.. happiness and sleepless nights..

Happiness: IE7 is coming with a bunch of features and bug fixes that allow us to think of a bright future where browsers co-exist in peace without making web developers struggle too much for delivering their cool web pages..

Sleepless nights: as described in previous post about CSS design patterns, a lot of websites rely on web browsers bugs for writing browser dependent rules in CSS. As there are (were?) still differences in browser rendering, CSS cant yet be written in independent manner. But with IE7 supporting fixing bugs and supporting CSS 2, all these rules become obsolete and rules written for firefox are now going to be applied to IE7. In some case it will work but we can expect a whole lot of websites designs that will break in the following weeks and months..

The second issue comes from the support of SSL in IE7 and FF2: they only support SSL version 2, which means that servers implementing SSL V1 wont work.. It sure going to involve some time fixing this issue..

But well, crises are meant to make us humain being evolve for the better, arent┬á they ­čÖé Good luck for everyone involved in web development and enjoy the new tools…

PS. for a solution on how to┬ásafely manage browser dependent rules in CSS, check previous post…


CSS design patterns for web 2.0

November 26, 2006


Summary: web 2.0 has seen dramatic changes in the way pages are developed. CSS standards are evolving to cope with the demand but in todays browsers web 2.0 requirements have outgrown CSS features and very few strategies are either defined or applied by CSS developers in the web industry. This makes web page creation a kind of black magic that is both expensive and risky as magic tricks might not work in next versions of browsers. This article describes the situation and provides 2 design patterns that make a significant change in developing web pages with direct returns on

  • css code reuse
  • quality,
  • safety of investments
  • ease of development and support of browsers.



As the web technology progresses on the client side with Web 2.0 being spread in the industry, we rely more often on both javascript and CSS for building websites and web applications. Whilst the javascript side is fairly well covered on the design side, with the knowledge derived from JS libraries (prototype.js, dojo, Y! UI, G! UI, etc.), we still don’t see enough efforts to rationalise CSS development (yes I know it’s a bold statement, but well just a view from my little corner, and anyway, I like bold statements :-).

We know that browsers are getting closer to each others in terms of CSS support. Thanks to Mozilla, we now have a decent cross platform browser that we can spot on our traffic analysis graphs without a magnifier. That means we now need to support more than one browser and it is a lot easier than it was with the evil Netscape 4 or Mac IE. But there are still some issues CSS developers (yet another title to put on already heavy CV in the industry) have to face nowadays…

First issue: font sizes and accessibility

By law, respect or any other reason, fonts in web pages that are written these days should scale well so that everybody can read them. To have fonts that scale well in all browsers, we should use units such as “em”, “%”, or “small/medium/large”, instead of “px” (pixels). However it is very difficult to use these units because:

  • “em” or “%” units are dependent on their context (what is the current font size), so any change in html or css can (and does) have side effects on other parts of the page. I know  it is possible to write pages like that but it is not easy and it is risky.
  • “small/medium/large” are the easiest and natural way of writing fonts that will scale well in any browser/device. However Mozilla, for probably a very good reason (what is it ?), displays fonts that are smaller than on any other browser. This breaks the design..

Conclusion: we can’t write accessible web pages with only a clean cross-browser CSS sheet.

Second issue: managing z-index

A lot of web applications now use drop-down menus or other widgets that display on top of others. In CSS, z-index property defines which layer should go on top of the other. Well, not always as IE has a bug for elements that are relatively positioned. It then breaks the rules and we have to apply special tricks well described in .

“height” matter

Not all browser support height properties the same way. IE6 allows to use the CSS “height” property for most html tags, whist in Firefox, the “height” is only supported (as defined in CSS standard) for block elements, and in any case, most of the time it is “min-height” that is equivalent to IE’s height .

Conclusion : getting the right height in CSS involves some kind of trickery to make every browser happy, and to play with “height”, “min-height”, line-height”, “padding” etc. until we get the right result in all browsers (whatever “all” means for you :-).

Lack of CSS reusability

HTML and CSS is often used beyond their limits and new de facto standards are created in this outland area. Examples are:

  • transforming ul/li lists into menus
  • creating side areas with floating divs (replacing tables).

Achieving these effects is not very easy because they use html/css features that were not designed for these purpose. The “float” property was mainly used to have floating text around images, not for replacing tables or create css menus. Although this works fine, CSS development is then quite difficult to write and then is more expensive. Also, because design pattern for reusability are not well known for CSS (apart from reading tutorials and rewriting things from scratch), we haven’t much CSS libraries on the market. Web development tools can help in some cases but not enough for making things any better.

Conclusion: CSS development is tedious and expensive because of lack of reusability and skill levels required.

Lack of common support for javascript behaviors in CSS

One design pattern that provides a direct impact on programming quality, time/money spent on projects of medium size is the “Model-View-Controller” or “MVC”. The basic idea is to separate things so that development can be done in parallel by different people (ex. graphic designer/html developer/javascript specialist/PHP developer/etc.). There are many other quality factors brought by this model (reusability, testing, maintenance, etc.).

In web2.0 applications, we can see components being implemented in web pages (ex. calendars, menus, other widgets, etc.). Modular Javascript libraries are available for helping in the development of such components, however it is still difficult to truly separate html from javascript the way html and css can be separated. The reason for that is we often need to attach a “behaviour” (such as opening a new window, adding a visual effect, etc.) to a piece of html and/or add html fragments in some specific parts of pages. To do so, we need to add <script> tags in the code. This solution is not very effective because html/css developers can’t write the page without either knowing javascript or work with javascript developers. This costs time and money and makes pages difficult to modify.

One excellent way to attach javascript behaviour to html is to put the attachment in a css rule. ex. { behavior: } . This example use IE syntax for attaching a javascript component (HTC) to html. Mozilla has another syntax for behaviours. The main issue is that we can’t use them because they are browser specific (and also some browsers have no support at all for behaviours).

Several workarounds have been added to js libraries but they are cumbersome, fairly slow and/or break the (x)html standard:

  • parsing the DOM and add behaviours to html elements with a specific css selector: cf. “behaviour.js” or “prototype.js javascript libraries.
  • parsing the DOM and add behaviours to html elements with a specific attribute. ex. dojo library with its “dojoType” attribute.
  • add XML tags in the html code and transform by js into components (ex. dojo tags <dojo:widget />)

These solutions are good enough and the best ones we have available but they can make page loading a bit slow. If a standard for web components was defined and supported in browsers, we would probably see a lot more reusable components on the market…

No Support in CSS for selecting rules by user agent

Because of several cross browser differences, CSS sheets have to be written in browser dependent manner.  How can this be achieved? As nothing in CSS currently helps in writing CSS rules dependent on the browser application (apart from “screen”, “print”, “tv” devices selectors for <link> tag), developers are using black magic based on application bugs or CSS level support:

  • some funny sequences of characters make a rule or part of the rule work in some browsers and not in others (ex. \*//*/ for IE/Mac)
  • conditional compilation in html is supported in IE (in html only)
  • IE6 doesn’t support the “>” parent syntax (as in ul > li), so rules written with this syntax wont be used by IE.

The fact we have to rely on bugs in internet browsers makes the development of pages both difficult and risky. Difficult because these tricks are not easy to achieve and are poorly documented. Risky because bugs could be fixed (we have seen these things happening, even in IE). So in next versions of IE or Firefox we could see a lot broken designs in websites… This could lead to some decent amount of money spent in fixing these websites. It actually reminds me of the huge work involved in fixing applications in year 1999 for supporting Y2K. Or business applications when the euro currency was launched in Europe…

Proposed solutions and design patterns

Solution 1: adapting standards and browsers to the reality of web 2.0 development.

The ideal situation would be to have CSS standard following the development reality by:

  • adding CSS selectors based on the user agent and/or browser application. It could be for example:
    gecko: body {font-size:small;} ie.5+ {font-size:x-small;}
  • or have CSS selectors based on supported features (css2: ul>li {})
  • create standard JS components via css behaviors.


Design Pattern 1: add support for browser dependent rules (without relying on browser bugs)

One way to distinguish rules supported by a specific browser is to add a class selector of the form: li { position:relative;z-index:100; }, body.ie_mac {position:static }.

Classes derived from the user agent can be added to the body tag at load time.

example (dependent on prototype.js):

// add support for user agent detection in document
Object.extend(document, {
getUserAgentClass:function() {
if (window.opera)
return “opera”

if (/MSIE/.test(navigator.userAgent)) {
if (/Mac/.test(navigator.platform))
return “ie ie_mac mac”
return “ie ie_win win”
if (/Gecko/.test(navigator.userAgent)) {
return “mozilla”
if (/Safari/.test(navigator.userAgent)) {
return “safari mac”
return “”

setBrowserClasses: function() {
// add user agent to body class

// add UA classes to body
Event.observe(window, ‘load’,document.setBrowserClasses);

NB. by applying this method, we make sure that CSS rules will be safely applied to a specific browsers and that these pages won’t break when browser bugs are fixed or when a new version is launched… This also makes CSS development easier and faster, in the short and long terms…

Design Pattern 2: use an modular/OO approach to CSS

CSS libraries can be implemented by using two interesting features in CSS:

  1. the ability to add several classes to an html tag. ex. <ul class=”horiz_list menu”><li>etc.. </ul>
  2. filtering CSS rules by a selector: ex. .horiz_list ul li {float: left;}. This feature limits the impact of defined rules to only a part of the DOM, thus avoiding side effects to other html parts in the page.

Combining these 2 features allow HTML/CSS developers to create CSS libraries that can be directly reused with less risks of having side effects. In the example above, the horiz_list class is applied to a <ul><li> to make it a flat list. The actual design for the menu (colors, fonts etc.) can then be defined in “menu” class, thus making it very easy to develop horizontal menus…

This example can be applied also to javascript components: separating the design of components (colors etc.) from their function (horizontal menu). We can then share CSS libraries across projects and people and make the creation of web page less tedious and expensive…


Developing CSS based pages is still difficult, expensive and risky because no actual design patterns or development standards are widely available or used by web developers. This could be easily improved by sharing the knowledge of CSS gurus (such as the guys at Zen garden and many others) into reusable CSS libraries or design patterns. This would help the web industry in getting better development quality at lower costs. The 2 design patterns described above could help achieving this objective and I hope that others will be available and applied in a near future…

About CSS fluid layouts

May 19, 2006

Use CSS sensibly and avoid CSS layouts


There are issues when using CSS layouts for creating multi-column pages.

I suggest to keep simple tables for splitting the screen into columns or to use JS behaviours for modifying the page onthe fly (page morphing).


If you are involved in web developemnt of some kind you are probably aware of the new way of writng web pages, thanks to CSS new design patterns. The basic idea is to write html pages with:

  • page structure in the html
  • look and feel (colours etc) in the css style sheet.

That's at least possible because all browsers ("all" meaning the ones used by 99% of people) now support a decent level of css.

So that's a new trend: forget putting colours in the html and put as much as possible of decoration in CSS.

This is the hot thing among html developers and that's really cool.

However as for every trend, we sometimes a step too far… Yes that is another example of the human brain pattern: we have found a new model and we becomes zealous… anyway..

The point here is: today it is cool to maximise the css side of pages and minimise the html part. And we use "CSS layouts" that are menat to replace html tables. So what does that means?

Before CSS, we had to heavily rely on table to display information invarious parts of the screen. Now we can replace most tables by css positioning rules (basicall x,y coordinates + ability to "float" areas around others).

And some smart blokes have come out with a few ways to take advantage of these features so that we can create columns in the page just by changing the css: we change the width of a text part, decide to make it "float" on the left or right and we do the same with other parts, and hurray"! we have created a multi column page without any html table..

Isn't it great? well yes and no… I know I know, I am supposed to say yes yes yes… css bla bla trendy, cool etc.

But I come from normandy in france, and there we say maybe yes, maybe no.

And that is exactly the answer I would like to say here. But her.. why?

The reasons we shouldn't abuse our html pages with css layout is because:

  • they are much more difficult to develop and tune (yes try it!!). It takes quite a few tests to really acheive the result we could get in 2mn with a simple table. I know because I have ot pay more for html development since I started using them..
  • they are not stable: it is like the box of chocolates in Forrest gump… With CSS layouts, we never know what we get  on screen (specailly on screens of our users). Havent you come across these sites where a part of the content is missing on the right or left and you find it at the bottom of the page, jsut like an old sock would fall on your shoes?
  • we need to express in too many details every size of the layout,
  • we cant have columns with the same heights if one column is going to be much larger than the others. It doesnt work in Opera for example.
  • CSS layouts often break page % measures. For example in a CSS column, a width of 100% doesn't necessarly mean 100% of hte width of the actual column, but sometimes 100% of the width of the whole page (or parent of column). This makes it difficult to add a dynamic web component in the column as the component no longer knows what the maximum size it can use on the screen…
  • this stuff is great with static pages, but static pages are something we dont do anymore, do we? Nah! Now we get the whole stuff from databases and apply some templates to create the content that we put somewhere on the screen. And funny things happen when a piece of content is larger by only 1 pixel than the size we have carefully definedin our css stylesheet. CSS layout break designs in dynamic pages!!!

The only case I would recommend css layouts is when we have a page that is aligned completely on the left side (as opposed to centered on screen) and we know exactly what we will put in the template.. So should we avoir using floating parts in our HTML? Of course not! "Float" properies are great for floating images asoide of text, for creating flexible tables (ex. a phto gallery) where we DO want the parts to move down when the screen size is reduced, etc. So in micro templates, that's a great way of doing things, but not in overall page structures.

Ok, so what's the right way to do it then?

1) structural approach to page layouts: 

Well, what we want is to create a layout with several columns right? Well I cant see why we can't express that in html. HTML is about structure and css abotu decoration. It seems to me that chossing to have column is a structural choice and not a decoration choice. And if we want to switch to another type of structure, it is easy with a template engine to do so.

2) use "page morphing", based on css/js behaviours

But if we want to really hide the page structure away from the HTML, we could use instead JS/CSS behaviours instead of strict CSS (I'll explain this method in following posts). Just like we can apply CSS properties to part of the HTML document using selectors, we can also rewrite the DOM with JS by using the same CSS selectors.

The advantage of this technic is that we are no longer limited to CSS capabilities and cross browser support and can then implement columns (or any other effect) in whatever HTML/CSS way we want without relying on CSS "float" property.

NB. CSS/JS behaviours are starting to be used with the release of the "behaviour.js" (check google!). It provides a true cross browser alternative to IE CSS behaviours (HTC etc.) and mozilla behaviour. This system, coupled with CSS and JS is going to provide a true revolution is the way HTML pages re going to be implemented. In short it is about replacing some bits of the HTML page by components, tranforming a simple HTML page into a very sophisticated DHTML page. It is a bit like CSS but with the ability to tranform the DOM instead of adding decoration features on it…