Posts Tagged ‘CSS’

Do you really know three layered webdesign?

Monday, January 12th, 2009

This is a topic that is well known and understood. Export the css layer and the javascript layer into files that can then be included in all your files, right? Not quite, that is an “object oriented” approach, which has nothing to do with three layered design. The “oo” approach is about unity and reuse of code. Many people have this misconception, and the result is that it is making an impact on the web in general.

It’s not only personal websites that fall into this trap. I stopped at McDonalds between Sydney and Canberra on a trip. To my great delight they had free wifi for their customers. So I pulled out my iPod and tried to connect. No dice. The EULA was Javascrip based, so I couldn’t click agree. And this is only one of many places that does this.

This brings us to the main question: What is the three layered webdesign theory?

three layered webdesign

three layered webdesign

There are many analogies used to explain this, and my favorite has always been the onion. Imagine a three layered onion. Look at it from the outside and you can see that it is an onion. Peal off one layer, and you can still see that it is an onion, a little bit smaller, but still an onion. Peal of one more and… you get the point.

Now after pealing off one or two layers, does the functionality of the onion decrease? No, it is still an onion and still does what it is supposed to do. In Webdesign; the outer layer is Javascript, middle is CSS and in the center is the content.

The theory states that you can not let the base functionality (submitting forms, navigating etc) of your site be dependent Javascript nor CSS. This has to be available in the content layer. You can’t use Javascript to load content, unless you make sure the content can also be loaded for a user who has Javascript disabled. Of course, you are allowed to change the content layer with the other layers, ie, changing the header text with an image using CSS. Or change how a form is submitted by changing the button using Javascript.

I am a firm believer of letting the majority of visitors have access to the content of my web sites. And I am sure all of your clients will agree to this. This means you will have to cater for people without 20/20 vision, or other disabilities. Using the three layered web design approach you are well on your way to achieve an AA, if not an AAA, WCAG rating.

Remember, about ten percent of the worlds male population (~300,000,000) is colorblind. Can you afford not to cater for this group?

Cascading order in CSS

Sunday, December 14th, 2008

I’ve been working with CSS for years now, and I’ve been following two simple rules about overriding styling rules. I like to call them the position rule and the origin rule.

  • The position rule
    If two or more rules with the same name exist, the latter wins and overrides the others.
  • The origin rule
    In line style rules overrides style rules in the header, and styles in the header overrides external style sheets

Example

Just following these two rules works in most cases, but can give you some interesting bugs. A bit deeper understanding of a third rule will help with these bugs and how to avoid them.

The third rule you need to be aware of is the specificity rule. This dictates that the more specific a rule is, the more weight it has, and thus it’s more important. Even if a rule is after that one, the latter will be ignored and the more specific will be used. It is pretty straight forward, and the w3 cascading rules does a good job of explaining the idea behind it:

A selector’s specificity is calculated as follows:

  • count the number of ID attributes in the selector (= a)
  • count the number of other attributes and pseudo-classes in the selector (= b)
  • count the number of element names in the selector (= c)
  • ignore pseudo-elements.

Concatenating the three numbers a-b-c (in a number system with a large base) gives the specificity.

Example(s):

Some examples:

*             {}  /* a=0 b=0 c=0 -> specificity =   0 */
LI            {}  /* a=0 b=0 c=1 -> specificity =   1 */
UL LI         {}  /* a=0 b=0 c=2 -> specificity =   2 */
UL OL+LI      {}  /* a=0 b=0 c=3 -> specificity =   3 */
H1 + *[REL=up]{}  /* a=0 b=1 c=1 -> specificity =  11 */
UL OL LI.red  {}  /* a=0 b=1 c=3 -> specificity =  13 */
LI.red.level  {}  /* a=0 b=2 c=1 -> specificity =  21 */
#x34y         {}  /* a=1 b=0 c=0 -> specificity = 100 */

Order doesn’t matter, and it only counts for one group at the time. IE: “UL LI, LI #rawr {}” gives us a specificity of 2 for first group and 101 for the second group.

The only other rule that over rides everything else is the ‘!important’ rule (buggy in IE6). Though, you can read that in the w3 cascading rule 6.4.2.