Over the past month I have been reading jQuery Enlightenment by Cody Lindley. Let me say now, that if you use jQuery or are thinking about using jQuery then you should most certainly buy this book. It’s a quick read (122 pages) that includes colorized code samples, easy to follow examples and solid explanations.

Author Cody Lindley is a member of the jQuery team and explains why he wrote the book.

jQuery Enlightenment was written to express, in short-order, the concepts essential to intermediate and advanced jQuery development. Its purpose is to instill in you, the reader, practices that jQuery developers take as common knowledge. Each chapter contains concepts essential to becoming a seasoned jQuery developer.

This book is intended for three types of readers. The first is someone who has read introductory books on jQuery and is looking for the next logical step. The second type of reader is a JavaScript developer, already versed in another library, now trying to quickly learn jQuery. The third reader is myself, the author. I crafted this book to be used as my own personal reference point for jQuery concepts. This is exactly the type of book I wish every JavaScript library had available.

I would argue that this book is perfectly suitable for beginners too. It’s simply a must have jQuery book. It’s the only one you need; it will take you from beginner to competent user.

I do ASP.NET / C# web development where I build web-based software for school districts. My preferred architecture is one in which I use NO server-controls. That means no GridViews, no Repeaters, no ListViews. If fact, nothing that uses runat server will be found on the page. The page will only consist of XHTML. So there is no need for a viewstate either. We end up using jQuery a lot in this architecture. We use jQuery / Ajax to call Web services that then query the database using LINQ to SQL and pass our data back to the client where we can then populate our XHTML controls. It works great and is extremely fast and efficient. The code couldn’t be cleaner. In addition, this methodology would allow you to easily change to a PHP or Java backend and you wouldn’t have to change a single thing on the frontend. I will give a full example on this methodology another time, but the point is – you need to learn jQuery.

For more information on the jQuery Enlightenment book, including a breakdown of each chapter go here. I would recommend buying the full color book from lulu.com as it’s well designed and very handy to have on your desk.

Try any of those footers from the Google search above in IE8 or Opera (some don't work in IE7 either). Load the page then grab the bottom of the window (not the side or corner of the window) and drag it up or down and you will see that the footer usually sticks in the wrong place, messing up the display.

Now try it on my old original sticky footer version (circa 2003 which pre-dates all those above) and you will see that my version is working in all browsers including IE8.

Before we get into details I should first explain what a sticky footer is.

What is a Sticky Footer

A sticky footer is one that sits at the bottom of the viewport when there is not enough content in the page to push the footer down. If there is a lot of content then the footer sits at the bottom of the document and will be below the fold as usual. Why this is desirable is because on short content pages you won't have a footer right at the top of the screen looking very strange indeed as shown from Figure 1 below.

Figure 1 - normal footer close to content.

Figure 2 - Sticky footer at bottom of viewport.

Note that a "fixed positioned" footer is not the same thing as a sticky footer as a fixed positioned footer is one that sits at the bottom of the viewport at all times and never moves. Don't get confused between the two.

Overview

Before we get into the nitty gritty detail I will briefly explain the concept in getting a sticky footer to work.

The first thing we need to do is create a 100% high container which is achieved by setting the html and body elements to 100% height and then creating a container that is a minimum of 100% high. The footer is then placed after this container which means it will be invisible as it will be below the fold of the page but by the magic of negative margins we can bring it back into view at the bottom of the viewport.

Of course this means that the sticky footer must be a fixed height (pixels or ems will do) so that we know how to accommodate it with the exact negative margins that bring it into view. This also means that our footer is now overlapping content on the page so we will also need to protect this content with either padding on an inner element, or some other similar approach as you will see when we get into specifics later.

That's basically all there is to it except that we have to squash a few bugs on the way to make it work everywhere.

When to use a Sticky Footer

Sticky footers are best suited for fixed width sites with small copyright messages and horizontal menu links that keep the footer at a relatively small size. The technique will work with a large height footer but the chances are that if you have a very large footer it will always reach the bottom anyway by the time you've got your header and content in place. It will also work with percentage width footers but remember that if the content in the footer is squeezed into making the footer higher than it was then the negative margin routine won't match any more and the layout will be misaligned slightly.

Creating The Footer

Now it's time to get your hands dirty with the code and I will break the method down in easy steps.

1) Create a 100% high wrapper to fill the viewport.

This is accomplished by removing the default margin and padding from the html and body elements and then setting a height of 100% so that our wrapper element can base its height on this. We then use min-height:100% on our page wrapper and not height:100% because our container would never grow otherwise but we will still need to address IE6 as it doesn't understand min-height at all. (If we didn't apply a height to html and body then our container would collapse to auto height and would not stretch to the bottom. The margins from html and body must also be removed because they would increase the height and thus ruin the effect as we want an exact 100% height only.)

As mentioned previously IE6 doesn't understand min-height therefore we provide a rule for IE6 only (using the star selector hack to target IE6 and under only) using the height property instead. We can do this because IE6 treats height as a minimum and will always expand an element to accommodate its content when overflow is set to visible (which is the default). We must also hide this height rule from other browsers because this would limit them to only an initial 100% and therefore the element would never expand with content.

Don't be tempted to use the !important hack to provide the height property to IE6 because the routine causes IE7 to be buggy with 100% height and won't resize the footer when the viewport is resized vertically.
i.e. Do not do this:

PLAIN TEXT

CSS:

1. #outer{
2.     min-height:100%;
3.     height:auto!important;
4.     height:100%;
5. }

Do not do this either:

PLAIN TEXT

CSS:

1. #outer{
2.     min-height:100%;
3.     height:100%;
4. }
5. html>body #outer{height:auto}

Both the above will fail in IE7 due to an obscure bug and should not be used in this routine.

The result of this code is that we now have a container that stretches to 100% height of the viewport quite nicely but the footer is sitting under this element and therefore under the fold of the page.

To bring the footer into view we first have to give it an appropriated height and then using a negative margin we drag it back into view. The negative margin can be applied in either of the following three methods.

1) A negative top margin on the footer itself
2) A negative bottom margin on the main wrapper
3) A negative top margin on the main wrapper

The first two methods are basically the same and just cause the footer to slip up over the bottom of the wrapper by the appropriate amount. Remember that the negative margins must match exactly the height of the footer. As a consequence of pulling the footer upwards it may indeed overwrite any content that was above it so you would also need to add some padding to the content above. The padding couldn't be added to the main wrapper because that means it would be too high and therefore the padding must be added to an inner element instead or just added to the element above the footer.

The third method mentioned above uses a slightly different tack in that the whole wrapper is moved upwards with a negative margin thus allowing the footer to fall into view at the bottom of the viewport but with the consequence that our wrapper now starts above the top of the viewport and out of sight. We therefore need to soak up this space on an inner element much the same as we did with the other two methods.

In 99% of cases you will most likely have a header element at the top of your page and you can use this element to soak up the extra space. My preferred method is to use a solid border on top of the header to do this because unlike padding it would not interfere with any absolutely positioned children should there be any.

Assuming our footer is 40px high the code to accomplish this is shown below:

The top border soaks up the space that is above the viewport and allows content to start in the viewport where it should be. This is exactly what we wanted and is quite a slick way to do this as we no longer need to worry about any overlap of the footer.

To make it easier to follow here is the code so far:

With the code shown we are very close to have a working footer and indeed the code above will work in IE6/7 and Firefox with no problems. Try out the above and see for yourself.

The problem with the above code is that it doesn't work properly in IE8 or in Opera. If, as already mentioned, you move the window by grabbing the bottom of the viewport (not the side or the corner) then the footer becomes mis-positioned or doesn't move at all.

This is the behavior seen in all other sticky footers but it doesn't occur in my original demo. The clue to why my old demo is still working will provide us with a neat solution that can be wrapped into this specific footer routine.

Back in 2003 not many browsers understood min-height and to accommodate these browsers I used a min-height hack which was basically a 100% high float that was 1px (or even 0px) wide. This held the browser open to the initial 100% height quite nicely without affecting much else as long as we took clear of clearing issues. The 100% height float triggered opera into resizing the page correctly once the viewport was moved and caused the footer to be drawn into the correct position.

Today (and thanks to the quiz I set at sitepoint) we can apply that 100% float using the pseudo element ":before" and negate the need for any extra html mark up at all.

The code above places a 100% high float that has no width as the first element on the page. This enables Opera to resize nicely and keep the footer where it should be. To negate any possible clearing issues on normal page content we use a negative top margin to pull the float high above the viewport (32767px is Opera's limit so don't use any more than this). Even with the negative margin applied Opera still continues to resize the page nicely.

IE8

The last browser to address is IE8 as it won't play ball with this method although it does understand the pseudo element :before, it doesn't apply the 100% height to it as required. Therefore we need another fix and again the answer is quite simple and logical and we supply IE8 with height:100% but declare the element as display:table. This will enable the element to be 100% high initially but also to expand if content dictates which is exactly the way that tables work.

As IE8 is the only one that needs this rule we will use conditional comments to supply this rule to it. In order to tidy up we can also remove the IE6 hack we added earlier and put it in the conditional comments as shown below.

If you are not familiar with the first line of the conditional comments shown above then in English it basically says "If less than or equal to IE6 or If greater than or equal to IE8 then use the code below".

As IE6 doesn't understand display:table then it is simply ignored by IE6 and it gets the height:100% rule only. IE8 on the other hand understands both and gets both just as it needed. This saves using two sets of conditional comments and keeps the page nice and tidy.

Here is the full code with comments to make it easier to understand or you can view source from the Full live version.
Full Code

Just in case you are thinking that there is too much code overhead in this if we look at the html needed you will see that there aren't really any extra elements (apart from assuming that you have a header in the page.) The minimum html is as follows.

I don't think you can get neater than that!

Although I have shown the example in a fixed-width format you can use it in a percentage or fluid width page as long as you take care with the footer dimensions and don't let the footer height increase with content. To enable text-resizing you could size the footer and negative margins using ems but that would assume you were basing them on the same font-size, etc.

Things to watch out for

Remember to take into account the effect of collapsing margins on the first and last elements in the wrapper because these may have an impact on the position of the parent or the position of the footer.

I also often see problems where authors have tried to make space at the top and bottom of the page by simply moving the wrapper down the page. The result of this is it moves the whole 100% down the page and ruins the effect. Everything has to happen in the 100% high wrapper and if you want space at the top then you would need to reduce the space at the bottom or be creative in other ways.

Here are just a few various examples.
Main Version
Example 1
Example 2
Example 3
Example 4

I hope you have enjoyed this article and if you have any questions then post away and I'll try my best to answer them.

I spoke to you back in January about Lijit. Remember I showed you that Lijit allows you to easily create your own search engine. One that searches your blog, bookmarks, photos, blogroll, and more.

I really liked Lijit then but I was disappointed that I couldn't integrate the Lijit search functionality into WordPress. That is let Lijit take over my search box that was already there and is ALREADY there in just about every other blog too. Instead you had to put a widget on your page. I felt like this was such a mistake I actually went to visit Lijit in Boulder and told them so. Well I'm happy to say that they have listened and now allow you to let their search take over your search box. Here's what they say:

Lijit's integration with WordPress.org just keeps getting better! Now you can either install the Lijit Search widget OR have Lijit power your existing WordPress search box. As if that weren’t exciting enough, our Lijit stats will automatically display within your WordPress dashboard for one-stop stats viewing too.

Go ahead and have a look, try the search located in the top left corner....

If you like it you can find the Lijit WordPress plugin here.

The above photo is my stack of geek books from last Christmas. Yes, I love books -- I love the way they smell, thumbing through the pages and oh yes, the wisdom they bestow. I admit, often times I don't make it through the entire book. Sometimes just a handful of chapters. But every now and then you come across some great books that are gems. So I thought I would share a few of my favorite books from this year.

Head First C#

Each morning before work I stop and enjoy a latte or cappuccino. This is my book of choice to read while sipping down my caffeine kick-start. That's because it's not like your typical code book which can be pretty dry. This book is very visual, full of pictures and diagrams that help to illustrate and drive home key points. Often times it finishes the chapter with a crossword puzzle helping you to retain the points of the chapter. In fact those crossword puzzles inspired this post. It's a great read for beginners and advanced users alike.

Object-Oriented ActionScript 3.0

If you are just starting to learn Flash or Flex or ActionScript then this is the book for you. Actually, even if you are a seasoned pro this is still the book for you. Why? Because it teaches you the correct way to do things. It teaches you true object oriented programming in ActionScript. With topics like: Encapsulation, Classes, Inheritance, Polymorphism, Interfaces, and Design Patterns you will not only learn ActionScript, but also principles of OOP. If you wish to learn proper Flash/Flex development then this book is for you.

The ASP.NET Anthology

This book takes a problem solving approach to a handful of common everyday ASP.NET developer needs. Things like: form validation, membership and access control, working with email, rendering binary content, Ajax, handling errors and more. Sitepoint says this about the book, which I agree with: "Solve specific ASP.NET problems fast — without wading through mountains of reference material — and rest assured your code follows current best practices. For the serious ASP.NET coder, this book is a must-have."

The Ultimate CSS Reference

Perhaps the last CSS book you'll ever need. Written by our very own Paul O'Brien whom regulars to Search-This will know does an amazing job making sense of often tricky, finicky or strange CSS behaviors. Almost every web site created today is built using CSS, which is why a thorough knowledge of this technology is mandatory for every web designer. There are plenty of good resources to help you learn the basics, but if you’re ready to truly master the intricacies of CSS, this is the book you need.

ASP.NET 3.5 Unleashed

Make no mistake about it, this is a reference book at almost 2,000 pages. But it may be the best ASP.NET reference book on the market. It covers everything: LINQ to SQL, ASP.NET AJAX, ListView and DataPager data access controls and all the rest. What's especially nice is that you can tell the author, Stephen Walther, has spent time in the trenches. He knows best practices, like using CSS for all his layout work and having well-formed cross-browser friendly code all the while teaching you ASP.NET 3.5. This is a must-have book for all ASP.NET developers.

Well there you have it, five of my favorite geek books of 2008. Do you have a book that you read this year that you thought was a gem?

For example, let's say you have a div with an id of "contentTop" like below:

Because you have made the control a server-side control by adding the runat="server" attribute it will now be rendered with a different ID when it hits the browser (view the source code and you will see). It will get rendered as something like this:

This is because ASP.NET generates its own IDs to ensure that every element on the page has a unique ID. Developers that work with JavaScript and CSS will immediately see the problem. This causes difficulty when using JavaScript and CSS which rely on those IDs to reference elements, as they can't easily predict what the generated ID will be. When it comes to CSS specificity the ID selector is extremely useful. In addition, anyone that uses JavaScript knows that getElementById (or one of the JavaScript library ways) is the most popular way to target an element. So why the hell does ASP.NET do this to us? Honestly, I can't really tell why, other than the fact that they must not trust us enough to be able to uniquely ID our elements ourselves.

But I don't want to just complain here, I would like to provide some solutions too.

Solution

The solution will be found in the ClientID property of the server-side control. The ClientID property represents the ID that ASP.NET will use for the element on the client.

Using the ScriptManager we place the ClientID in a hidden form field. This can all be done in the code-behind file by using the following code:

Be sure to have included the ScriptManager to your page, like so:

Now we can use JavaScript to retrieve the value from our hidden form fields.

That's it, if you know of another way, please let us know.
Happy coding.

I am going to start by showing the finished product as this will help you visualize what we are going to achieve along the way. Figure 1 below shows a smaller version of the task ahead.

Figure 1

We are going to make a similar display but without using tables as in my view the information presented is not tabular and does not have a logical correspondence between rows and columns. Even if you do present a good case of why this should be in a table, please don't comment on this as we are interested in the layout techniques rather than perfect semantics (for this example). The techniques presented here can be used in other layouts that are certainly not tabular and will prove useful in many situations.

Define Your Content

The first thing we need to do is decide what elements we are going to use to style this category list. That's your first clue - we should already be thinking about using a list to do this. However, I feel that information like this is more suited to a definition list (DL) as the product name is the data term (DT) and the description underneath is the data definition (DD). (Feel free to disagree but whatever method you choose the techniques used to construct our layout will likely be the same.)

I'm using a Definition List which will allow us to semantically describe the heading and the associated text that describes the heading.

Although definitions have default styling applied, such as margins, we can simply get rid of that using one of the many reset techniques available. I am using a global reset for purposes of the demo but I suggest you look into more thorough methods.

Lets' start by thinking about what we want to achieve.

The image needs to be at the left of the layout and the text needs to be lined up nicely alongside the image but we don't want the image to wrap underneath the image as that looks a little messy in a list like this.
e.g. Not like this:
Figure 2

As you can see the last line of text wraps under the image rather spoiling the effect so we will look at how to overcome this problem without complicating the issue too much.

The image can be floated to the left and we can apply a right margin to push the text away at the side. So for a start we will do just that and see what our display looks like.

HTML

CSS:

If you run the above small code sample you will see a display almost exactly as that shown in Figure 2 above. The image is floated nicely to the left and the text wraps to the right side of the image except that the last line wraps under the image.

We will address that issue in a moment but it's important to mention at this stage that floats are removed from the flow and if you want them to stay inside your container you must use some sort of clearing mechanism. Otherwise the float will float out of the container and poke into the container below should content be less than the height of the image.

In our example I have added overflow:hidden to the dl container which will ensure that all floats are contained within. Overflow other than visible will cause elements to contain their floated children in most modern browsers. IE6 needs "haslayout" to be true and then it will auto clear floats also. This can be achieved by setting a dimension which we already have in place so no extra hacks are required. Overflow isn't always the most suitable clearing mechanism to use but in simple layouts it works well but you should investigate other clearing techniques also.

Additionally, note that I have placed the image inside the dt element because the product image and it's title are really the same thing.

Stopping The Text From Wrapping

Usually authors would apply a left margin to the text content to make it steer clear of the image but this is not the best solution for three main reasons:

1) Firstly your images may be supplied dynamically and be of varying widths and therefore your left margin approach would fail unless you set a width wider than all the images.

2) The second problem would be that IE6 has a "3px jog" on static content next to a float and would make the display look slightly odd. Sometimes this is barely noticeable but it can still be annoying.

3) Lastly and more importantly, if you have floated content mixed in your content description section and you try to clear them you will end up clearing all floats and the whole description drops below the float. Figure 3 shows an example of this.

Figure 3

(Example shows what happens when a float (the red box) is cleared)

Luckily there is a simple method we can turn to that cures all these problems quite easily. (As an aside this method was also exploited earlier in one of John's Articles.) If we once again use overflow other than visible on this content we can make it form a rectangular box to the side of the image and also honoring the image's margins. It's almost as if we have floated another block to the side except that we haven't.

The overflow:auto (or overflow:hidden) causes the element to form a rectangular block that will not only stay at the side of the floated image but will also contain any floated children. As another bonus It will also contain the effect of any clearing of floats in that section. Float clearing from within that overflow:auto container will be restricted to that container only and not just clear all floats above in the HTML as per usual.

The overflow method doesn't work in IE6 but fortunately forcing "haslayout" on the element concerned has exactly the same effects and with an added bonus of partially curing the "3px jog" mentioned earlier. As we don't want a dimension in this container we can use the height:1% hack supplied via the star selector hack to target IE6 and under only.

Therefore all we need to add to the CSS already shown is this:

If you run that code you will get a display similar to Figure 1 above.

The only extra element in Figure 1 is that I have placed some text to the right of the product title. I did this by placing the text in a strong element and floated it to the right. However as floats need to be in front of the content that they will wrap (except for inline content on the same first line as the float but few browsers obey this anyway so its not worth arguing about) I have moved the strong element in front of the product description as follows.

There you have it. With relatively little code we have avoided a number of bugs and behaviors and produces a nice looking layout. I mentioned earlier that our fix only partially cured the 3px jog and the eagle eyed among you will note that although there is no jog on the content it does happen to be 3px further away than other browsers. If this is an issue for you then you can always offset this with a hack that applies 3px less right margin on the image. However I don't think many people will notice so I am not bothering to apply another hack.

The finished layout can be found here and I suggest that you copy the code from the demo itself (view source) if you want to practice these techniques.

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?

Those are our ten things any web developer worth their spit should know. What do you think? Did we leave anything off the list that you think we should have included?

This love to build something from nothing still resides within me; it's just been replaced with web technologies instead of plastic bricks. Today I build websites, plugins, widgets and anything else that takes life in my imagination. The thing I enjoy most is seeing if I can pull it off -- can I get what's in my head to take form on the web? Most of the time I can.

But there's something that really bugs me about all of my creations. They simply don't last. In fact, over the years I've found the life span of any web-based product to be short, very short. Of all the websites I've built, more are gone than remain. They've been replaced by newer versions or completely phased out. There's no place for nostalgia on the web.

I have a deep jealousy of designs that last. I look at Michelangelo's Sistine Chapel which has been around for five hundred years and is in no danger of ever being updated or phased out. Or Beethoven's 9th symphony which he completed in 1824 and still moves the soul today. I'm betting that even more recent artists like Christian R. Lassen probably never worries about their work becoming dated and needing to be replaced. But in the world of computers, nothing lasts.

Does anyone else find this frustrating or at least a little depressing? Of course it's not just my work. I already have images of a new 3G iPhone dancing in my head and my current iPod is only two years old. My three thousand dollar computer that I hand built from the greatest specs three years ago doesn't run today's DirectX 10 games. How sad...

You have to ask yourself when developing software or web pages if pixel perfection's really all that important when it's only going to last a handful of years anyways? Could this be why Microsoft released Vista knowing full well that it was far from done? Microsoft is already talking about their next OS, Windows 7 and Vista is barely out of the wrapper.

I know, it is what it is, the beauty and the curse all rolled into one. The ability to create knowing full well that you will do it all over again in a handful of years. I guess it's job security, right?

Your thoughts?

Of course this is all by design – Howard Schultz, then CEO of Starbucks made a trip to Italy during which he visited some 500 espresso bars in Milan and Verona. He observed local habits, took notes on decor and menus, snapped photographs, and videotaped baristas in action. He was looking to create the right perception.

Now compare this to McDonald’s – what’s your perception of McDonald’s? Probably fast, convenient comfort food; who do you think would have a better cup of coffee, McDonald’s or Starbucks?

Perception dictates reality – Starbucks coffee tastes better because the consumer thinks it tastes better. But, a recent Consumer Reports found that McDonald’s coffee was actually better than Starbucks. That is the power of perception!

So when you start to build a website it’s imperative that you know the perception you want the website to present.

If you are developing a website for a client you need to learn how the company is currently perceived in its market. Are they seen as: conservative, progressive, friendly, formal, casual, serious, experts, humorous, service-oriented, professional or otherwise? Are they going to wish to strengthen this same perception through their website or are they looking to make a change?

What challenges are they facing getting their image across to customers? Or maybe they are doing a good job with this and you need to learn why they are successful so you can be equally successful with their website.

A company's perception will impact the overall design of the website. Take GEICO and Allstate: they are both insurance companies, yet each conveys a different perception. The perception of GEICO, with its humorous speaking gecko and the “So easy, a caveman can do it” ads has a more relaxed feel than the Allstate insurance company with its more formal "You're in good hands" ads. We might anticipate that the websites for these two insurance companies could be completely different even though they are in the same field.

Perception is powerful, it’s how we see things – not how they really are.

If you were to ask someone what they feel about the company after they have left the website, that’s the perception the site is giving off.

I know some of you said it was a little tough, but hopefully you enjoyed it? Besides, it's good to stretch your brain with a good crossword or sudoku puzzle from time-to-time.

HERE ARE THE ANSWERS:
Web Crossword Answers PDF

Web Crossword Answers GIF

This crossword puzzle's questions cover such topics as: search engines, CSS, C#, JavaScript, Browsers, Programming and just about anything else Web-related, just like Search-This does.

So get yourself a cup of coffee and download the PDF file or view the image and print it out. Good luck geeks!

There are 25 questions. The answers will be posted next week.

Download Web Developer Crossword Puzzle

You can also click here to view an image of the crossword puzzle and print it should you want to.

In a previous article we learned how to apply some nice shadowed corners and sides to a fluid width box and I thought it would be good to show a similar method that allows for transparent corners. This will allow the element to sit on any colored background without having to paint the transparent part of the corner with the background color.

I know you might think "Oh no - not another round corner tutorial" but stick with it and I'm sure you'll find some of this info useful. Round corners are always a bit of a pain to do in CSS so I present here an easy to follow way to make round corners that can be used everywhere. We aren't going to do anything clever or overly complicated and we aren't going to bother with shadowed corners/sides because as I mentioned above we have already been there.

Before we begin here is a finished example for you to look at.

In order to use the round corner on different backgrounds I am going to use an image using the PNG8 (Portable Network Graphics) format with alpha transparency as shown by Alex in this useful article. If you don't have Fireworks or want smoother corners in IE6 and under then you will need to make images with the appropriate color background in the normal GIF (Graphic Interchange Format) format.

Here is the type of image I will be using for the following examples:

Figure 1

The image is a white circle with a 20px diameter that I have placed on a green background so that you can see it and so you can see what the effect will be against a different color background. (The real image won't have a green background of course.)

As you can see the image displays nicely on the green background in browsers that support alpha transparency because the corners are transparent. In IE6 and under the corners will appear slightly more jagged but eminently usable. What's good about this is that no hacks or filters are required.

Here is a magnified screenshot of the top left corner in IE6 and IE7 to show the differences:

Figure 2

That looks quite acceptable to me and if it's acceptable to you then we will plow on with the demonstration.

I should point out that you will need to create different colored circles if you want your elements to be different colors but unlike other methods you don't have to worry about the background of the elements that your box is laid upon.

One Size Fits All

We are going to use a single image (20px x 20px) to provide our rounded corners and to save on using different images we will use one image only and simply place each corner into place using the background-position property. The image is completely round but I'll only be showing one quadrant of it at a time and therefore we can supply all four corners with one simple image weighing in at only 300 bytes.

Figure 3

The benefit of using a single image is that all corners get loaded immediately after the first corner is drawn so there is virtually no delay.

Cut It Out

You may think that you could simply place the image in the four corners of a rectangular box but things aren't as simple as that. Our box needs to have a background color and as we are using a white corner image we need a white background for our box. However, if we place a transparent corner in the corner of that box then in fact nothing really happens. The reason is that the transparent part of the image lets the white background show through and all we get is the square box we started with.

In order for the corners to work properly the corner of the box must be over the background color of the element outside our current box. We therefore need to drag the round corners outside the box to start with but that presents more problems. Here is a screenshot of what the corners will look like outside the box so you can understand what's going on

Figure 4

As you can see we have a problem whatever we do! If the images are inside the rectangle then they become invisible. If they are outside the rectangle then it looks even worse as figure 4 above shows

What we really need is a rectangular box where the four corners are cut-out to give a cross-shaped effect. If we made sure that the cut-out matched the radius of our circle (10px) then we could pop our corners nicely into place.

We can achieve this by nesting an inner box inside our outer box and then dragging it outside of the parent using a negative top and bottom margin. If we also give side padding to the parent and top padding to the child we can get a cut out effect like this.

Figure 5

The CSS mark up for this is as follows:

Followed by the simple HTML:

The next step is to provide four elements and place our corners into position with static positioning. We will be leaving a 10px padding around our box so that we have room to position the corners nicely without affecting the inner content. (Don't be tempted to use absolute positioning because IE is always 1px out when the distance traveled is an odd pixel number. This happens on right and bottom absolutely placed elements and can destroy a layout like this.)

I am going to use a div with nested span to provide elements for the corners but if you wanted to reduce mark up you could use a nested "b" element as suggested by Eric Meyer (although its use for background images is not likely to be very semantic). Using a nested b element would also negate the need for a class as you are unlikely to have any other elements like this on your page. Anyway I am sticking with the div and nested span as it is easier to follow.

The HTML we need for this is as follows:

The extra div and span has been placed inside the .inner element which means we must drag the top corners upwards into the padding area and then outwards into free space so that the transparent corners can show. The reverse process is needed for the bottom corners. There are a couple of "haslayout" bugs to squash on the way and IE6 also needs position relative applied to make the corners show.

The revised CSS and HTML for the whole section is shown below.

I have also added a content div in the middle just to tidy things up and the revised HTML is as follows:

The font-size:10px in the CSS is there to restrict IE's height to 10px; otherwise it would increase the element to the full current font-size and spoil the effect. The result of the above code can be seen in these live examples:

Example 1

Example 2

Example 3

For ease of use the CSS has been left in the head so that you can view source and inspect it easily.

Not Floated

The above example uses floats to hold everything together but we can simplify this a little and use static elements instead. Instead of floating the outer we can give it a width or leave it as width:auto and set the margins accordingly. Once again IE6 needs a helping hand and we have to use the ubiquitous "haslayout" fix to bring it all into line.

The only thing worth noting is that now that the main element isn't floated you will find that margin collapse affects the negative margined corners in Firefox and in order to stop the margin collapse we will simply add a 1px border in the current background color. This will cure the effect quite simply (read more about collapsing margins in a previous article.)

Here is the revised CSS:

HTML:

As you can see in Example 5 things are looking better now and much easier to control. You can even nest the boxes quite easily now.

What about borders?

If you want to add borders to the element and the corners then you will need to make a new round image with the border color that you require. We can then add CSS borders to our layout to match up and complete the illusion. Unfortunately you will need to make two images this time because of course the bordered part of the round corner that extends into our layout will show. We can get away with two images because some of the image will already be covered up by the negative margin we used on the content.

Here is a screenshot of what happens when just the single image is used:

As you can see some of the border has already been rubbed out so we just need to make images without the sections that are visible above. Two images will be enough for this.

If you don't mind a couple of hacks you can drag the inner content over the visible part of the border and the whole thing can be done using one image only as shown in this live example and in the screenshot below.

I would recommend, however, using two images and avoiding the hacks to keep things simpler. You should be able to work out what's going on by looking at the source code so I won't go into more detail and leave that as an exercise for you.

Drawbacks

The main drawback is once again the extra html mark up required to place each corner and if that upsets you then you may want to try one of the many javascript solutions that are out there.

There is also extra maintenance involved with the negative positioning that we used and you will need to take this into account when you place the corners alongside other elements as they will overlap other elements if you don't allow about 10px more space than you thought you needed.

In addition, the first examples make a lot of use of floats to hold everything together and you may need to wrap the whole lot in a static element if you need to place it somewhere (see example 4 above). Example 5 is the most stable version and the method I recommend you use but either method will work following the guidelines already outlined.

IE6 is also a little jumpy on fluid floated layouts at small screen sizes but that's nothing new and something you'll have to live with. Example 5 does not suffer from this though because the outer wrappers are not floated.

The advantage of this method is that the image is only 300bytes and you are not restricted by size like most other methods that use a massive image to draw the sides and borders. The above examples can have unlimited width and height and carry virtually no overhead in file size apart from the extra HTML of course.

I started out by saying this was simple but due to bugs and browser differences it wasn't really that simple was it? Please refer to the examples for the full code as there are some fixes in place for the various demos. Have fun playing with the examples and if you find a better method of doing this, or want help with the above, or if you find some bugs then let's hear from you.

What Does It Mean?

Curly braces should feel comfortable to any CSS author, since you cannot write any useful CSS without them. Regular parentheses should be fairly familiar, too, at least if you've used functional notations like background-image:url("/images/bg.png") or color:rgb(128, 128, 255). But square brackets?

The square brackets denote an attribute selector – a concept that was introduced in 1998 in CSS Level 2. An attribute selector modifies a simple selector by imposing an additional constraint on it. Does that sound like Greek to you? (Or like something other than Greek, for those of you who are, in fact, Greek?) Don't worry, we'll look at some examples in a short while.

Why Should You Even Bother?

But first, let's address another question: If attribute selectors really are useful, why didn't you already know about them? Or, to turn it around, since you've managed to get by without them, what's the point of using them?

The reason you may not have heard about them is quite simple: Internet Explorer for Windows up to and including version 6 don't support attribute selectors. Since the market share for those browser versions has been well above 80% until very recently, there hasn't been much incentive for using attribute selectors in public-facing websites.

Version 7 of IE does support attribute selectors, though, and as more and more users upgrade from IE6, attribute selectors gain more interest.

What can those newfangled attribute selectors do then, that's so useful that you should take some of your precious time to learn about them? The answer is that they allow you to do a lot of things that you hitherto have had no other way to achieve than to pollute your markup with class attributes.

How Does It Work?

As I said before, an attribute selector is a modifier on a simple selector. A simple selector, as you may recall, is made up by the following components:

• a type selector, or an implicit or explicit universal selector
• an optional ID selector
• zero or more class selectors
• zero or more pseudo-classes
• zero or more attribute selectors

As we shall see, class selectors are really just a special case of attribute selectors.

Let's look at some simple selectors and identify the different components.

h1

This selector consists of a type selector and nothing else. It matches all elements whose element type is h1.

#nav

This selector appears to contain only an ID selector, but there's a bit more here than meets the eye. The selector is actually *#nav, but it's customary to omit the universal selector (*) when it's implied. So there's a universal selector and there's an ID selector. The combination will match any element whose ID attribute has the exact value “nav”. Since IDs must be unique, this selector will match at most one element on the page. The implicit universal selector means that it will match this element regardless of what element type it has.

a.external:visited

This selector consists of a type selector (a), a class selector (.external) and a pseudo-class (:visited). It matches some hypertext anchors (links) that the browser considers unvisited. Some? Yes, it only matches unvisited links that belong to the class external, i.e., whose class attribute contains that word.

All right, but what about those attribute selectors? There are four different flavors in CSS2, and another three that are defined in CSS3. All seven flavors are implemented by the latest versions of the mainstream browsers: IE7, Firefox, Opera and Safari. Note that IE6 is conspicuously absent from the list. It has no support at all for attribute selectors.

Let's look at the different flavors, then.

Attribute Presence

[title]

This CSS2 attribute selector matches any element that has a title attribute specified. It doesn't matter what value the title attribute has. As I'm sure you know by now, the selector is really *[title] with an implicit universal selector.

The attribute name is an identifier, so don't put any quotation marks around it.

This may not appear to be very useful at first, but it actually does come in handy at times. Say that we want to provide a visual clue – a dotted bottom border – for any element that has a title attribute, to alert the reader that there's an advisory title available which may be displayed as a tool-tip. We'll also change the mouse cursor for those elements, to emphasise that the tool-tip is meant as some form of help to the reader.

Simple Attribute Value

input[type="submit"]

This CSS2 attribute selector matches any input element whose type attribute has the value “submit”.

The attribute value can be specified as a string (enclosed in quotes) or as an identifier (no quotes). I generally prefer to use strings, myself.

The attribute name is case insensitive in HTML (including pretend-XHTML), but case sensitive in XML (including real XHTML). The attribute value may or may not be case sensitive in HTML, depending on the attribute. In real XHTML all attribute values are case sensitive.

We can use this to style form buttons without having to resort to a class:

Note that [id="nav"] is not equivalent to #nav. The two selectors will match the same element in HTML or XHTML, but the latter has a much higher specificity than the former. (Specificity is a concept in the cascade, which decides which style rules take precedence over others in cases of conflict.)

Also, [id="nav"] matches an element with an attribute named “id”, whose value is “nav”. On the other hand, #nav matches an element whose ID attribute has the value “nav”. Does that sound like six of one and half a dozen of the other? It's not, actually. An ID attribute is one whose type is declared to be ID in a DTD, XML Schema or similar. It doesn't have to be named id at all. And an attribute named id doesn't have to be an ID attribute. In HTML and XHTML, the only attribute of type ID happens to be named id, but that isn't necessarily the case for XML applications in general.

Attribute List Value

p[class~="literary"]

This CSS2 attribute selector matches any paragraph element that belongs to the class literary. To be more specific, it matches paragraphs whose class attribute is a space-separated list of words, one of which is exactly equal to “literary”.

In other words, it will match all of the following paragraphs:

But it doesn't match either of the following paragraphs:

“Hold on!” I hear you cry, “that's just like p.literary, isn't it?” Indeed it is. That's why I said before that the class selector is really just a special case of an attribute selector. Class selectors only match class attributes, though, while the full syntax can be used for any space-separated attribute value, like td[headers~="price"].

[lang|="en"]

This CSS2 attribute selector matches any element whose natural language is specified as English. To be more specific, it matches elements whose lang attribute is a hyphen-separated list of words beginning with “en”.

In other words, it will match all of the following elements:

But it doesn't match an element with lang="sv" or lang="fr-be".

The CSS2.1 specification doesn't state whether it's allowed to use a value that contains a hyphen with this syntax (like [lang|="en-gb"]). Browsers generally accept it, though.

This flavor is similar – but not equivalent – to the :lang() pseudo-class selector, which isn't supported by IE7 or Safari. The main difference is that the pseudo-class selector also matches elements that have inherited the language value from an ancestor element.

Partial Attribute Value

a[href^="http:"]

This CSS3 attribute selector matches link elements whose href attribute value starts with the string “http:”.

img[src$=".png"]

This CSS3 attribute selector matches image elements whose src attribute values ends with the string “.png”.

input[name*="choice"]

This CSS3 attribute selector matches any input element whose name attribute value contains the string “choice”.

Words of Warning

There must be no white space between a type selector (or universal selector) and an attribute selector meant to modify it. White space is the descendant combinator in CSS, so a [href] means a *[href], which is something quite different from a[href].

Some attributes in HTML and XHTML have default values: values which will apply even if the attribute isn't even specified for an element. One example is the method attribute for form elements, which defaults to method="get" if omitted.

Attribute selectors in CSS are only guaranteed to match attributes and values that are explicitly specified. The selector form[method="get"] is not guaranteed to to match a form element with a start tag like <form action="vote.php">.

There are also some issues concerning value matching of minimized attributes. Attribute minimization is an SGML feature that is commonly supported for certain attributes in HTML (but not XHTML). A minimized attribute consists solely of the attribute value; the name and equals sign are omitted. For instance, <select multiple> is equivalent to <select multiple="multiple">.

Firefox and other Gecko browsers treat a minimized attribute as if it were specified as an empty string (multiple=""). Opera, on the other hand, treats it as if it were specified as multiple="true".

But What About IE6?

Right, this all sounds lovely, but IE6 and older don't support attribute selectors and are still used by several million people. Isn't this just an exercise in futility?

It's not. I wouldn't have bothered writing this article if it were.

Of course we cannot rely on attribute selectors any time soon. What we can do, however, is to use them for progressive enhancement – adding value for modern browsers without causing any harm to older browsers.

My earlier example on how to style form buttons, for instance, shows one way to progressively enhance the aesthetics. In IE7, Firefox and Opera, buttons will be blue, while in IE6 they will have the default Windows look. Safari doesn't allow styling of form controls, so it will retain the native look, too, although it does support attribute selectors.

The point is that we can use attribute selectors today. As the market share for IE5 and IE6 diminishes, attribute selectors will become more and more useful and our markup can become leaner and cleaner.

The project was a redevelopment of a very large community to include implementing a new design by the client. The redevelopment included porting over old functionality into new code, implementing several new features, and integrating a new design that was provided to me and my partner by the client. We worked on the project for several months and had a pretty good relationship with the client.

We were about 90% done with the project and were wrapping up a lot of things. The client asked us to implement something and I really didn't understand what he was asking for so he told me he would show me an example. He took me to a link and when I clicked on the link, my stomach sank. I was looking at an exact duplicate of the site we were creating except for some slight color changes. I immediately went to Domain Tools to check how long that site had been up. My initial thought was the other website somehow copied his. The idea that he copied this website design and it's functionality hadn't crossed my mind until I saw the website had been in existence for a couple of years.

I said to the client, "This site looks just like yours!" and he wasn't sure what I was talking about and we went back and forth on whether it looked just like his site and finally he admitted that he had taken a screenshot of the design and completely copied it. I felt very disappointed and somewhat deceived actually. Here is someone I grew to know and had regular conversations with, yet he hadn't been honest with me. I immediately started thinking about the project. We were so close to being done, yet it now turned into something that we could never put in our portfolio. That wasn't the biggest issue though; it was the unethical actions the client took, didn't disclose to us, and brought us in as an unknowing party to this. At this point I needed to decide whether we would continue with the project or stop where we were and hand over the code.

I took some time to think about it and talked it over with my partner as well as some colleagues. We really just wanted to finish the project but we didn't want to do anything that could hurt our business. A big factor in our decision was to think about it as a new project. If the client would have come to us in the beginning and told us that he wanted to completely rip this site's design and functionality, would we have accepted it? The answer was definitely not.

We have a clause in all of our contracts that basically says that either party can cancel the contract for any reason. We simply must give them the code and they pay anything that is due for that code. So, that is what we did. This isn't something we wanted to do, but we don't want to work with people who aren't honest with us and who we feel are unethical as it can hurt our business. I still feel a slight conflict about firing the client as I really wanted to finish the project because it was a pretty cool one, but it just wasn't worth it, so we handed over all of the code.

As I said in the beginning, I've been in business for 5 years and never had to worry about something like this before, but it is something every developer should consider and be prepared for. The first thing to do is make sure you have a contract and in that contract give yourself a way out if you ever encounter a situation similar to mine. This clause should also protect the client if they are unhappy with your performance for any reason.

So how do you decide when to fire a client? It really comes down to your business and how you want to run it. If the client has asked you to do something that could affect your business poorly, this should raise a red flag. It isn't a decision that should be taken lightly and only done in situations that you feel very strongly about.

Have you ever had to fire a client? What would you have done in my situation?