Now that IE7 has overtaken IE6 in usage it has become more common to find authors trying to use position:fixed in their layouts. Therefore in this article we will try to address some common problems and misconceptions when using position:fixed (we will not be covering the background-attached “fixed” property but you can find out more about that here if you are interested.).

Note that position:fixed doesn’t work in IE6 and under so you will need to be using another browser although we will try to accommodate IE6 with some alternate styling.

Fixed to What?

Fixed positioning varies from other positioned elements in that the element is always placed in relation to the viewport and not a local stacking context. Even if you add position:relative to a parent of the fixed element it is still placed in relation to the viewport.

This can present problems if you want to place the fixed element inside a centered layout and then place it at a certain position within that centered layout.

In order to have a positioned element inside a centered layout you can simply let it occupy its normal position in the flow and not specify any position values for top, bottom, left or right at all. This will enable the element to become fixed at that point while the rest of the content scrolls.

We’ll work through some simple examples to show this in effect.

We’ll start with this simple Example

Click to continue reading »

• Diablo 3 - Oh Yeah!! Be sure to watch both videos!
• Funniest Thing I’ve Seen in Awhile - Watch both videos and read what the guy did. Great Stuff!
• Google Improved Flash Indexing - Very nice - very nice…
• Tiger Woods Website - He may be the best golfer in the world, but his website sucks…
• Out Of Your League Girl On Confidence - Um, strange…
• Browsershots - Test your web design in different browsers…

This year I have found myself looking for jobs on two separate occasions. As a result I have had a good number of interviews. One question that I found harder to answer than I had anticipated was when asked how good I am at JavaScript and CSS.

Why was this question that hard to answer? I actually feel that I am quite knowledgeable about both CSS and JavaScript. I’ve built probably close to a dozen websites using entirely CSS-based layouts over the last few years. In addition, I have used JavaScript quite often to enhance those websites, usually with Ajax and spiffy web widgets like the Comment Info Tip Plugin. I may not be as knowledgeable as Paul O’Brien when it comes to CSS or Jonathan Snook when it comes to JavaScript, but I certainly am competent. So again, what’s the problem?

The problem is the damn cross-browser problems that still trip a person up from time to time. Almost every time I ask Paul for his help with CSS it has to do with a cross-browser issue: something works in Firefox, but not in IE or vice versa. Same with JavaScript; think addEventListener method in Firefox and attachEvent for Internet Explorer. This is a bloody mess for the developer and I suppose makes me question my abilities at times.

Such cross-browser issues make it hard for a developer. I don’t know about you, but I’ve often spent more time trying to make a site work across all browsers than on the actual design of the site.

There are people that I know and respect that have chosen not to learn JavaScript at all because they were so put off by such difficulties. Also consider how difficult it’s been to get people to leave HTML table-based designs behind in favor of CSS layouts. It’s been slow at best. No doubt due much to the differences across browsers.

What’s your take? How has the difficulties in trying to achieve all browser support effected your attitude of CSS and JavaScipt?

• photoShuffle - Nice Flash photo album…
• Ironman Desktop Wallpaper - Good movie, good wallpaper.
• Aaron Cannon’s Web Accessibility Checklist - Aaron Cannon is a blind web developer and accessibility consultant.
• The Clone Wars Trailer - Let’s just hope Lucas didn’t write it.
• The Clone Wars Trailer 2 - How long until video games look this good?
• What are C# Generics - Part I - Nice article…

1. DOCTYPE Declaration

   DOCTYPE (short for “document type declaration”) informs the browser of which HTML or XHTML standards you would like your code to be checked against. You’re essentially declaring to the browser that these are the rules that you have used to create this page and in return you are expecting that it will render accordingly. Failure to specify a DOCTYPE can lead to unexpected rendering — a developers worst nightmare.

   [ further reading ]

2. Navigation

   A website’s navigation plays a key role in the success or failure of a site. It allows humans and search engines alike to easily locate the desired information. Or it doesn’t. Navigations made up of Flash or JavaScript/DHTML may seem attractive at first, but ultimately can cripple a website by not allowing search engines to crawl and index the entire site. In addition, viewers that choose not to partake in these technologies can be left with no means to move within the site.

   Most experienced webmasters have left such navigations back in the 90’s with all those AOL discs.

3. CSS is Not an Option

   In the past webmasters could choose to ignore CSS if they so desired. Those days are gone. CSS is no longer an option, it’s part of the trifecta (see The Separation of Concerns for the trifecta) that makes up a quality website. A good webmaster will use CSS exclusively to define the look and layout of a website.

4. The Separation of Concerns

   In days gone by web developers would meld HTML, CSS, and JavaScript code all into a single page; like a web page jambalaya. Inexperienced web developers may still do this, but the experienced ones took notice that the make up of any given page is defined by three elements: the content of the page, the presentation of that content and the behavior of that content.

   Realizing this, competent developers have made an effort to keep these three layers separate from one another. Kevin Yank does a fine job explaining our three layers in his article: Simply JavaScript: The Three Layers of the Web

   When building a site, we work through these layers from the bottom up:

   1. We start by producing the content in HTML format. This is the base layer, which any visitor using any kind of browser should be able to view.

   2. With that done, we can focus on making the site look better, by adding a layer of presentation information using CSS. The site will now look good to users able to display CSS styles.

   3. Lastly, we can use JavaScript to introduce an added layer of interactivity and dynamic behavior, which will make the site easier to use in browsers equipped with JavaScript.

5. Cross-Browser Support

   Any developer that has been building websites for awhile has the battle scars that you get when you try and make your website work on all browsers. Each browser has it’s own idiosyncrasies (some more than others) and designing and redesigning your site to function under each can be a battle; but it’s a battle that must be fought and won.

   [ for more help with cross-browser CSS read this ]

Click to continue reading »

• Golden Ratio Calculator - Nice idea…
• Microsoft Visual C# Under the Covers: An In-Depth Look at C# 3.0 - Video - about 1 hour long.
• LINQ to SQL: Accessing Relational Data with Language Integrated Query - Another 1 hour long video on LINQ.
• Thrasher Magazine - How many people got this mag when they were a kid? I did.
• Powell-Peralta Future Primitive - Yes I’m reminiscing about my skateboard days; ah good times…
• 24 Kick Ass Portfolio Designs - Some great work here…

In recent thread over at the SitePoint forums, someone asked how to have any sized image fit nicely into the viewport while maintaining its aspect ratio. The assumption is that all the content can fit in the viewport and no scrollbars are needed. While CSS is wonderful and magical, it doesn’t know the sizes of images and let us play with them to pixel perfection, so we must turn to good old JavaScript to maintain aspect ratio.

Click to continue reading »