All posts tagged ‘stylesheets’

File Under: CSS

Why Percentage-Based Designs Don’t Work in Every Browser

Here’s a rule any web designer can live by: Your designs don’t need to look exactly the same in every browser, they just need to look good in every browser.

It’s a maxim that will spare you many a hair-pulling hour. That said, there some things you would expect to be the same across browsers that aren’t. One such problem that’s likely to crop up more often as designers jump on the responsive, flexible-width bandwagon is percentage-width CSS rules.

According to the spec, browsers, given a percentage width, would simply render the width of the page based on the size of the container element. And, in fact, that’s what browsers do, but how they do it varies quite a bit. As a result, percentage-based widths are often displayed quite differently across web browsers.

Developer Steffan Williams recently ran into this problem when trying to create a percentage-based version of his Gridinator CSS framework. Williams created a container <div> with a width of 940 pixels and then wanted to create a 12 column grid within that container. Do the math and you end up with columns set to a width of 6.38298 percent.

Pull that up in Firefox or Internet Explorer 6/7 and you’ll see what you expect to see. In Safari, Chrome and Opera, however, you’ll see something different. IE 8 and 9 are also slightly off.

The problem is not a new one; developer John Resig pointed this out years ago. But as Williams notes, it’s odd that browser behavior when rendering percentage-width grids is still so inconsistent across vendors, especially given how much today’s browsers tout their CSS 3 support.

The problem isn’t necessarily a simple case of Firefox and IE being right and the others wrong. As Opera CTO and CSS creator Håkon Wium Lie tells Webmonkey, the problem is “the CSS specification does not require a certain level of precision for floating point numbers.”

This means browsers are free to round your carefully computed percentages up or down as they see fit. According to Lie, Opera considers the result of Williams’ experiment to be a bug. Same with the WebKit project, the engine that handles rendering in both Safari and Chrome, though in Webkit’s case the bug has been unassigned since 2006. But really, there is no right or wrong here, just different ways of rounding.

Continue Reading “Why Percentage-Based Designs Don’t Work in Every Browser” »

File Under: CSS, Web Basics

How to Speed Up Your Site With YSlow and Page Speed

We all want our websites to load faster, but speeding things up can be tricky. There are numerous tried and true tricks we all use to keep page load times down, but once you’ve done a few rounds of optimization, you tend to hit a plateau where it’s tough to squeeze any more speed out of your code.

Most web developers are familiar with tools like YSlow and Google’s Page Speed. If you haven’t ever used them, go install both right now — they’re available as add-ons for Firefox. Both tools are designed to help you speed up your site’s page load times by showing you exactly what’s slowing them down, and used in tandem, they can alert you to some optimizations you never knew existed.

I recently sat down and tried, as best I could, to do everything that YSlow and PageSpeed recommended and I managed to shave my page load time roughly in half. When I started, my homepage took between four and six seconds to load. Now, it loads in one to three seconds on average.

To compare load times I used both YSlow and PageSpeed, as well as WebPageTest. Those numbers aren’t exactly benchmarks, since there’s some speed variation depending on what’s loaded in the cache, but a performance increase of about 30-40 percent is what you can expect if you haven’t yet explored these methods.

Some of what YSlow and Page Speed will tell you should be obvious — limit your HTTP requests, minimize, compress and combine your JavaScript and CSS files, use CSS Sprites, put your script tags at the bottom of the page and compress your images.

However, some of the more obscure and less-used (judging by viewing source code around the web) techniques these tools point out can make a surprising difference.

Before we get to the “how to” part, keep in mind the old saying “premature optimization is the root of all evil.” What I did with YSlow and its ilk was the last bit of optimization I did. In other words, be sure you’ve taken care of the big problems before you try to stamp out the smaller ones.

That said, I was surprised by how much of a difference some very small changes made.

Continue Reading “How to Speed Up Your Site With YSlow and Page Speed” »

File Under: CSS, Web Standards

Dealing With Browser Differences in CSS 3

Woolly, the CSS sheep.

Cutting edge web technologies never come without a cost.

Sometimes it means limited browser support for emerging standards, and other times it means having to go back and rewrite your code when draft standards change.

When it comes to the still-in-progress CSS 3 spec, not only does browser support vary widely, but most browsers have implemented what are know as vendor-specific prefixes. The prefixes complicate things, and they require more work to drop them into your code, but they do serve a purpose.

For example, if you want rounded corners in CSS 3, you’d use border-radius to define them. But because border-radius is still being finalized, browsers only support their own versions of the rule. So, -moz-border-radius will target Firefox, -webkit-border-radius targets Safari and Chrome. For Opera, it’s -o-border-radius.

None of the special prefixes will validate, which is less than ideal. There’s a suggestion floating around that CSS validators should change their behavior regarding vendor prefixes by issuing a warning instead of an error. Regardless, if you want absolute standards conformance in your CSS code, you’ll need to stay away from vendor prefixes.

However, if you want to play with CSS 3′s new toys, you’ll see there are some very good reasons why vendor-specific prefixes exist, and why you should use them (for now) in addition to the actual proposed rules of CSS 3.

To stick with the border-radius example, consider what happens when you want to target just one corner of an object. The spec was in flux in when the WebKit project decided to use -webkit-border-top-right-radius and Mozilla went with -moz-border-radius-topright. Without the prefix, you’d have to deal with two different CSS rules, potentially forever, with one of them eventually being depricated, but still out there in older versions of that browser.

Both prefixes are technically “wrong” and that’s a good thing. Eventually, the final spec will be published and only one rule will be standardized, with all browsers implementing that rule. At that point, you can simply go into your code and delete all of your prefix rules. The vendor names make them easy to find and zap.

One thing you should definitely not do is target only one browser’s prefixes. As Apple’s disingenuous “HTML5″ showcase recently highlighted, optimizing for a single browser is never a good idea.

If the idea of vendor-specific prefixes strewn about your otherwise standard CSS makes you uneasy, there is another possibility — offloading all the prefixing stuff to JavaScript.

Developer Arron Gustafson has written a critical article for A List Apart where he derides vendor-specific prefixes and offers a JavaScript alternative for those who feel the same way he does.

Gustafson refers to vendor prefixes as “forking” CSS. While we agree with his point, the word “forking” is problematic if only because there is nothing wrong with forking code. In fact, it’s the norm in the open source world. (You are using Git or Mercurial right?). And vendor prefixes are not forks, they’re hacks — temporary ways to push the boundaries of the web while standards bodies catch up.

Terminology aside, Gustafson’s point is valid — ignoring standards and littering your CSS with browser-specific code are both bad ideas.

Gustafson’s little JavaScript library can help you avoid vendor prefixes in your CSS. But, impressive as the script is, all it really does is offload the prefixing to JavaScript. The approach has some downsides — it means additional page load times and it neglects users who have JavaScript disabled.

If you want to start using CSS 3′s features now, you’re not going to avoid vendor prefixing, but at least you can choose how to handle it. Whether that means using the prefixes in your stylesheet, putting your vendor-specific code into separate stylesheets, or using a JavaScript solution like Gustafson’s is up to you.

See Also: