This post on CSS calc() on HTML5Rocks got me thinking about how I could use calc() and have it work cross browser. Calc() will be a valuable feature in CSS3 once it is supported. The biggest thing it allows you to do is mix percentage and absolute values as well as mix sizing units.
The biggest problem with calc() right now is that it is not well supported. Firefox supports it with the ‘-moz-‘ prefix, and Chrome will add support in version 19 with the ‘-webkit-‘ prefix. IE9 has support for it, un-prefixed. Because of the vendor prefixes, I’m guessing for now, cross browser syntax would look something like this.
width: -webkit-calc(50% - 100px);
width: -moz-calc(50% - 100px);
width: calc(50% - 100px);
In the above example, I provided a fallback for older browsers first, followed by the 2 vendor prefixed versions and finally the un-prefixed version. See the gist here.
While thinking about using calc(), I wondered if Modernizr had a test for it. I was sure it must but discovered that it did not. While it looked like someone tried to add a test, it was missed. So I contacted Paul Irish and asked him about it, and he worked with the original developer to add the test. You can now run the test in Modernizr to see if it is supported and write different CSS rules based on that. But you still need to provide and fallback and use the vendor prefixes.
It also got me wondering about how calc() would work in a language like Sass. I’m assuming you would just write it out and it would work, but since Sass has it’s own method for doing calculations, it’s worth exercising caution.
I can’t wait until we are able to use calc() to calculate values in CSS. It’s the first step to being able to use something like Sass in the browser. But until it is well supported, it requires you to write multiple rules. If you are opposed to that, you should stick with Sass or Less which do the calculations and conversion for you.
If you are familiar with concept of Responsive Web Design, you should also understand fluid layouts. Sass, the CSS pre-processing language, has a few features to assist you with calculating values for fluid layouts.
This tutorial shows you how to calculate percentages with the percentage function in Sass and also how to write a custom function in Sass to convert pixel values to ems.
Responsive Web Design in Sass Part 1: Fluid Layouts and Fluid Images – Intermediate.
You should be using Sass already because it supports variables, functions and nesting. But if you’ve been holding out for some reason, now you have another reason to use it. This is the future of CSS.
This is an easy fix, but I thought it was worth a post anyway, in case someone comes across it.
overflow: hidden on a block element does not work in IE, if width and height are not set. But, it does in other standards aware browsers.
You may come across this situation if you have an element nested inside another element where width and height are set, and the nested element is inheriting the dimensions of the parent element. In that case, there is no need to set width and height usually. Well, in IE,
overflow: hidden will not work if no dimensions are specified.
So as you may have already guessed, the fix is pretty simple. Setting a width and height on the element, or even just a width, will cause IE to obey the property.
I’m not sure if IE is doing the correct thing or not, in this case. It does make sense that you would have to specify dimensions, so that the browser will know where to cut it off at. It seems though, that IE is dumb here, as other browsers assume the inherited dimensions. I’ll leave that up to you to decide.
Those familiar with CSS 2.1 may be familiar with the CSS property
display: inline-block. This property allows an object to have the properties of both an inline object and a block object. What this means is that the object can be displayed inline but have height and width qualities of a block object.
This is a property that can be very useful when applying certain layouts. I was using it on a project recently when I discovered that Firefox 2 lacks support for
display: inline-block. This was quite shocking to me because I assumed that Firefox 2 had full support of CSS 2.1. After all, Firefox was the number one Mozilla browser until only recently.
Anyway, in searching for a work around, I discovered that there is a similar Mozilla-specific CSS property that works in the same way,
display: -moz-inline-box. All you have to do is add that property to your CSS and you will get the same effect in Firefox 2.
However, I discovered another problem with this in that once you apply
display: -moz-inline-box to an object you can no longer use
position: absolute on any objects contained within that object. I continued to be amzaed by Firefox 2’s misbehavior.
I finally discovered a solution to this as well, although not ideal. After searching a bit more, I found that if you add an second
div inside the object, you can apply
position: relative to that, which will then allow you to position objects absolutely within that
div. Make sense?
In case you were wondering, the reason it is not ideal is that you are adding an unnecessary
div to your code for simply presentational purposes. It is never good to do this, but sometimes the trade off is worth it for full cross browser support, when your layouts are more complex.
I discovered an interesting bug that occurs in both IE 6 and 7 the other day. Actually, I had seen it before, but I had never been able to figure out a cause or a fix until now.
The bug occurs when you have a background set to no-repeat on an element with an undefined width. When no width is set on the element, usually because it’s inside a parent element that has a set width, the background repeats vertically in IE 6 and 7 even when the background is set to no-repeat.
The fix is easy. Obviously, if this bug occurs when no width is set on the element, simply setting a width fixes the problem. The background will no longer repeat and will show up as it is specified. There you have it!
File this one under, you may have seen it before, but I ran across a very weird IE6 bug yesterday. This bug gave me a fit, and I hadn’t encountered it before, at least I don’t remember it.
The problem was an empty div with a height set to 6px. The actual height in IE6 was 18px. If I set the height to 20px, it would be 20px, but if it was less than 18px, it would stay at 18px. Well, it just so happens that 18px is the line-height. So what’s happening is the empty div is inheriting the line-height, even though there is no text inside the div. Go figure.
Another interesting thing is that reducing the line-height doesn’t fix the problem. No matter how I tried, it stayed at 18px. Even setting the line-height inline doesn’t work. What does work is setting the font size to 0. This fixed it instantly. So remember, if you are using empty divs in IE and they are smaller than the line-height, you need to set font size to 0.
See the screenshot below and click on the link to see an example.
Today I learned that there is a “nowrap” equivalent in CSS. Nowrap is an attribute of the td or th tag that is deprecated in HTML 4.01. Nowrap tells the table cell not to automatically wrap the text contained in the cell.
The CSS 2.1 specification has a property called “white-space.” One of the values of white-space is nowrap. I tested this property, and it works the same as nowrap does. I also confirmed that it works in IE6, IE7 and Firefox 2.
So, if text automatically wrapping is a problem for you, don’t use “nowrap” because it is deprecated. Instead use the white-space property, with nowrap for the value. I added the property as an inline style rather than in the stylesheet, so that I didn’t have to create another class and I can use it only where it is needed. How you use it is up to you.
Lately, I have found that it is easier to allow a page to display differently in IE 6 than it is to make that page display the same way in IE6 as it does in other browsers. Think about it. Let’s say you have 4 browsers. Your page looks the same in 3 of the browsers, but in one of the browsers, it doesn’t quite look like it should. You could choose to spend extra time to find a work around to make it display the same across all 4 browsers. You could even go so far as changing the layout of your page. Or you could simply allow it to display differently in that one browser, and move on to the next project.
If someone has a problem with it, the solution is simple. Upgrade. Or change browsers. It makes sense, and it pisses me off I didn’t start doing it sooner.
Now before people go and get all upset, I am not advocating designing your site to purposely look bad or crappy in IE6, just different. For example, say you have a div with a transparent PNG as a background. IE6 lacks support for transparent PNGs, thus requires a work around hack to display a transparent PNG as a background. You could implement the work around hack. Or you could just set the background as a solid color in an IE6 only stylesheet using conditional comments. The solid color background won’t look as good as the transparent PNG, but it works fine. Someone using a browser that supports transparent PNGs will have a better experience, but it still works.
Finally, I know that we all have clients, and our clients drive most, if not all, of the work that we do. If a client wants it to look a certain way in a certain browser, then sometimes that’s just the way it is. But I bet if you tried reasoning with your client using the above argument, you just might persuade them to see things your way.
Update: I forgot to add that making things display differently in IE usually requires the use of an IE only stylesheet with conditional comments.
If you ever wanted to know how support for CSS improved in IE7, this post is for you. Apparently in August 2006, before IE7 was released, Microsoft posted these details on the IE Blog. The post details all the bugs that were fixed, added support for W3C specifications and features added for CSS 2.1. I always wanted to know this, and this is the first time I have seen it.
They go on to talk about how fixing support for CSS will cause a lot of the hacks that worked before to break in IE7. This page details specifically which workarounds that previously worked in IE6 will not work in IE7.
I believe IE7 has now been out for over a year. I admit I am impressed with Microsoft’s support for CSS in IE7. It is worlds ahead of IE6. However, the adoption rate that I have seen for IE7 over IE6 is still very slow. In addition, how long will it take for Microsoft to release IE8? Five more years? By that time, IE7 will be outdated as IE6 was. Unfortunately, as many inroads as Firefox has made into browser market share, we are still living in a Microsoft world. Maybe by releasing Safari 3 on Windows, Apple will be the one to change that. It is still in beta as of this writing, though.
I don’t usually do link posts, but I thought in this instance it was worth mentioning. I recently discovered 2 posts on Eric Meyer’s blog dealing with reset styles. So what are reset styles and why do we need to use them? For that, read Eric’s post, Reset Reasoning. In this post, Reset Reloaded, Eric lists exactly what his reset styles are so you can use them.
I think that Eric is right in using them. It does seem like reset styles are a better alternative than using a universal selector to remove margins and padding because, as Eric says, the universal selector removes padding and margins from everything. There are some cases where you might not want to do this, such as form elements.
I think I am going to give reset styles a try. How about you?