Albert Holtsclaw

One of the first traps people fall into when learning CSS deals with the mystical float property. Floating content in pages is something that needs to be done with finesse or you can get some weird behavior in your pages.

Some people dismiss this weird float behavior as a browser quirk instead of trying to understand the issue. I thought I would take a quick second to document how floated elements interact with their parent container.

Floating elements takes the elements out of the “normal flow” of a page. Therefore, they are not included in the height calculations of their parent containers. This can cause overlapping content in pages or even more odd behavior. There are convoluted ways to fix this, including adding markup to your pages with the clear property on them to reset your floats.

But, there is a more elegant way and it only takes two CSS properties on the parent container.

.parent {
overflow:auto;
_height:1%; /* ie6 fix */
}

In most cases, overflow:auto will force the height of floated child elements to be included in the height of the parent. And the _height property (yes it is misspelled with a leading underscore) will fix an issue in IE6 where overflow:auto isn’t enough to force height to be calculated. It turns out that IE6 doesn’t mind a leading underscore and accepts the property, but virtually all other browsers fortunately drop the property as being invalid.

See the following image and webpage for an example of this in practice.

Example: http://www.albybum.net/docs/css-examples/floats.htm

Having professionally worked on high-profile websites with Web developers of varied skill levels, I have seen first-hand the recurring common CSS mistakes that people make and the frustration and lost sleep that comes from those mistakes. Even after doing this for years, I still find myself repeating some of the same.

Even though CSS is an easy language to understand, it takes years of experience to master all the language and cross-browser “gotcha’s” associated with Web development. I think a recent SixRevisions article by Max Luzuriaga describes this well.

But despite its deceptively easy exterior, CSS is one complicated system, especially when you’re doing it in a professional, high-scale, high-performance level. The sheer number of ways to select an element is amazing; not to mention the number of properties you can apply to that selected element set and then how presentation changes when you’re talking about supporting multiple browsers and layout engines.

It’s easy to get tripped up with CSS.

For a while, I have wanted to document these issues for myself, but it was difficult to find the time. Now that I do have the time, I plan on making a series of public posts documenting these issues myself and finding professional supporting articles.

To start, I highly encourage people read the above-mentioned SixRevisions article. I will describe below the two points that I do not 100% agree with. But, it is a great read and points out some of the common high-level issues with CSS.

Source: 12 Common CSS Mistakes Web Developers Make (SixRevisions)

Over-Qualifying Selectors:
Problems can definitely arise from being too specific with selectors, but the opposite is true as well. If style rules are applied to selectors that are too generic, then more specific selectors that are needed as sites evolve often have to “undo” or overwrite inherited rules in these new rules.

Just as a very simplistic example, adding font-weight to the base anchor tag element selector would cause every link to inherit this rule. Most likely, there are going to be links somewhere on your site that you don’t need to be bold. So, any more specific selectors added “down the road” would have to reset this font-weight value. Again, this is a very simplistic example, but the concept still applies if it was prefixed by a #sidebar selector or even more nested and specific selector.

a { font-weight:600; }
#sidebar a { font-weight:600; }

Using very specific ID selectors as “prefixes” can also allow developers to easily and somewhat semantically “segment” their style rules to target specific sections of a site. This is useful for large websites with multiple sections or tools that might undergo revisions separate from the remainder of the site.

I think the solution here is to use the exact level of specificity needed to achieve the current style with some planning for the future and some consideration of how the rules will be reused. For example, what selectors might be nested within the current selected element or container that will also be affected by the associated rule? I think many Web developers do not give enough consideration on how style rules on a site will interact with each other. And, this leads to more issues other than just selector specificity issues.

Using Only One Stylesheet for Everything:
Using multiple stylesheets can be a mixed blessing for maintenance. If there is a high level of cohesion in the style rules being bundled (like CSS reset, IE fixes, etc.), those can make maintenance easier. In this scenario, things can be easier to find and change.

But, I argue that segmenting CSS into separate files for “sections” of a website can be a mixed blessing. Things are often not as cohesive as we would like after a site has been in maintenance mode for a while. And finding where a style rule is defined can be a pain in these scenarios, which are more common in large development studios. This is especially a problem when style rules affecting an element are cascaded across multiple files.

Whether segmenting offers a benefit or a hassle for maintenance really is negligible if you use the right supporting tools like Firebug – as it usually make tracing style rules trivial.

The real issue that comes to mind for me is performance. Splitting CSS into multiple files creates the need for additional HTTP requests, which is one of the banes of performance for high-load websites. This is the same reason we use the sprite technique to bundle multiple design images into one image and use CSS to position the right image into view. Lowering the number of HTTP requests increases performance.

Splitting CSS into multiple files can give a net performance gain if the site in question has a ton of CSS, some of which doesn’t always need to be loaded. CSS rules for a lower-traffic section of the site could be factored out into a separate CSS file and only linked when the specific sections are loaded. But, it would take some analysis of whether those extra kilobytes are worth the extra HTTP requests.

Update 1, 9/8/2010:
Reading through the comments at SixRevisions, I noticed the recommendation to use @import to address the HTTP request issue when splitting up CSS files, but @import has its own set of performance issues by forcing sequential loading.

This is a very interesting multimedia proof of concept done with HTML 5.

From the “video,” I noticed at least the use of HTML 5 video, canvas and geo-location features. There may also be some persistence of data. This definitely illustrates some new ways that websites will be engaging visitors in the future, allowing a more personalized multimedia experience.

I was surprised at the smooth integration of elements between technologies and how great the drawn images actually looked.

Google is a big proponent of HTML5, especially for video and rich graphics in the browser. To show off what HTML5 can do, Google Chrome teamed up with the Arcade Fire and director Chris Milk to create a custom interactive video for their song, We Used To Wait. The experience is called The Wilderness Downtown and is best viewed in Chrome

I definitely encourage people to fire up Chrome and take a look.

Source Techcrunch (via Digg)

In a move that defies logic, Microsoft is actually RAISING the price of XBox Live instead of moving toward some ad-driven service.

Source: http://www.engadget.com/2010/08/30/xbox-live-gold-price-increasing-as-of-november-1-in-us-uk-cana/

The change takes effect in November.

So, I guess if you want in on the cheap, stock up on those existing cards now before the price goes up.

Well, this is sad and unexpected: Microsoft’s Major Nelson just announced that Xbox Live Gold will be getting more expensive in the US, UK, Canada, and Mexico starting November 1. A single month will go from $7.99 to $9.99, three months will go from $19.99 to $24.99, and the yearly sub will now be $59.99, up from $49.99.

According to Wolfram Alpha, today is my 10,000th day alive.

Interestingly, if I reverse the logic, the calculation falls 7 days short.

But, this calculator, also says 10,000 days.

So, I guess I’ve lived “approximately” 10,000 days