The Principles Of Cross-Browser CSS Coding

The Principles Of Cross-Browser CSS Coding

• By Louis Lazaris
• June 7th, 2010
 
• CSS, Essentials, Testing
 
• 260 Comments

Advertisement

It is arguable that there is no goal in web design more satisfying than getting a beautiful and intuitive design to look exactly the same in every currently-used browser. Unfortunately, that goal is generally agreed to be almost impossible to attain. Some have even gone on record as stating that perfect, cross-browser compatibility is not necessary.

While I agree that creating a consistent experience for every user in every browser (putting aside mobile platforms for the moment) is never going to happen for every project, I believe a near-exact cross-browser experience is attainable in many cases. As developers, our goal should not just be to get it working in every browser; our goal should be to get it working in every browser with a minimal amount of code, allowing future website maintenance to run smoothly.

In this article, I’ll be describing what I believe are some of the most important CSS principles and tips that can help both new and experienced front-end developers achieve as close to a consistent cross-browser experience as possible, with as little CSS code as possible.

(Smashing’s note: If you enjoy reading our articles, you'll love the Smashing eBook Library. Get immediate access to all Smashing eBooks with 70% discount and vote on the topics you’d like to learn more about. We’ll prepare eBooks that fit your needs best! Subscribe now!)

Understand the CSS Box Model

This is one of the first things you should be thoroughly familiar with if you want to be able to achieve cross-browser layouts with very few hacks and workarounds. Fortunately, the box model is not a difficult thing to grasp, and generally works the same in all browsers, except in circumstances related to certain versions of Internet Explorer (more on this later).

The CSS box model is responsible for calculating:

• How much space a block-level element takes up
• Whether or not borders and/or margins overlap, or collapse
• A box’s dimensions
• To some extent, a box’s position relative to other content on the page

The CSS box model has the following basic rules:

• Block-level elements are essentially rectangular (as are all elements, really)
• The dimensions of a block element are calculated by width, height, padding, borders, and margins
• If no height is specified, a block element will be as high as the content it contains, plus padding (unless there are floats, for which see below)
• If no width is specified, a non-floated box will expand to fit the width of its parent minus padding (more on this later)

Some important things to keep in mind for dealing with block-level elements:

• If a box has its width set to “100%”, it shouldn’t have any margins, padding, or borders, otherwise it will overflow its parent
• Vertically-adjacent margins can cause some complex collapsing issues that may cause layout problems
• Elements positioned relatively or absolutely will behave differently, the details of which are extensive and beyond the scope of this article
• The rules and principles above are stated under the assumption that the page holding the block-level elements is rendered in standards mode (this point was added later after review of the comments posted)

The box model as its displayed using Firebug in Firefox

Understand the Difference Between Block and Inline

For experienced developers, this is another no-brainer. It is, however, another crucial area that, when fully understood, will cause the light bulb to appear, many headaches will be avoided, and you’ll feel much more confident in creating cross-browser layouts.

The image below illustrates the difference between block and inline elements:

Here are some basic rules that differentiate block elements from inline:

• Block elements will, by default, naturally expand horizontally to fill their parent container, so there’s no need to set a width of “100%”
• Block elements will, by default, begin at the leftmost edge of the parent box, below any previous block elements (unless floats or positioned elements are utilized; see below)
• Inline elements will ignore width and height settings
• Inline elements flow with text, and are subject to typographical properties such aswhite-space, font-size, and letter-spacing
• Inline elements can be aligned using the vertical-align property, but block elements cannot
• Inline elements will have some natural space below them in order to accommodate text elements that drop below the line (like the letter “g”)
• An inline element will become a block element if it is floated

Understand Floating and Clearing

For multi-column layouts that are relatively easy to maintain, the best method is to usefloats. Having a solid understanding of how floats work is, therefore, another important factor in achieving a cross-browser experience.

A floated element can be floated either left or right, with the result that the floated element will shift in the specified direction until it reaches the edge of its parent container, or the edge of another floated element. All non-floated, inline content that appears below the floated element will flow along the side of the element that is opposite to the float direction.

Here are some important things to keep in mind when floating and clearing elements:

• Floated elements are removed from the flow of other block-level, non-floated elements; so in other words, if you float a box left, a trailing paragraph (block level) that’s not floated will appear behind the float in the stack, and any text inside the paragraph (inline level) will flow around the float
• To get content to flow around a floated element, it must be either inline or else floated in the same direction
• A floated element without a declared width will shrink to the width of its content, so it’s generally best to have a set width on a float
• If a block element contains floated children, it will “collapse”, requiring a fix
• An element that’s “cleared” will avoid flowing around floated elements above them in the document
• An element that’s both cleared and floated will only clear itself of elements that come before, not after

Use Internet Explorer First (Or Don’t)

Please note that Smashing Magazine’s team strongly advises against developing websites in Internet Explorer first. In our opinion, sites should be developed in “modern” web-browsers, with standards first and then be tweaked for buggy versions of Internet Explorer. The advice below does not reflect the opinion of the Smashing Editorial team. Agree or disagree? Comment on this article!

Most of what I’ve discussed so far has to do with CSS coding and layout principles. This principle is more related to habits and preferences of most designers. Although we might hate to use IE6 and IE7 in our everyday internet activities, when it comes time to build a client project from scratch, one of the best things you can do is test your layout in those browsers early in development. You might even want to open up a standalone version of IE6 or IE7 and just start your development in that browser.

Of course, you won’t have access to tools like Firebug, but generally for CSS (especially early in development) you won’t need Firebug. It’s much easier to get a layout working first in IE6 and IE7, then fix for other browsers, than to do it the other way around. Waiting until late in the development process to open up IE6 and/or IE7 will likely cause some, if not all, of the following problems:

• Multiple hacks will be required, needing separate stylesheets for different versions of IE, making the code bloated and less maintainable and making the website slower
• The layout in some spots may have to be reworked, multiplying development time
• Testing time will increase, sometimes exponentially, leaving less time for more important tasks
• The layout in other browsers will not be the same as in IE6 and IE7

I wouldn’t expect developers to use Internet Explorer this aggressively for personal projects, web apps, or other non-client work. But for corporate clients whose user base is primarily on Internet Explorer, this tip could prevent a lot of headaches while getting things to work properly, and will definitely make a cross-browser experience much more likely.

Sometimes viewing IE’s problems as “annoying bugs” can create unnecessary negativity, and can hinder development time and future maintenance. Dealing with IE is a fact of life for designers and developers, so just view its problems as you would any CSS issue — and build from there.

Understand Internet Explorer’s Most Common Problems

If you’re going to start with IE in your development, or at the very least check your layout in IE early on, then you should understand what things Internet Explorer (usually versions 6 & 7) has problems with, or what its limitations are.

A detailed discussion of every possible problem that can occur in Internet Explorer, and a list of all of its CSS compatibility issues is certainly beyond this article. But there are some fairly significant inconsistencies and issues that come up in relation to IE that all CSS developers should be aware of. Here is a rundown of the most common problems you’ll need to deal with:

• IE6 will become problematic if floats are overused, causing (paradoxically)disappearing content or duplicate text
• IE6 will double the margin on floated elements on the side that is the same direction as the float; setting display: inline will often fix this
• In IE6 and IE7, if an element doesn’t have layout, it can cause a number of problems, including backgrounds not showing up, margins collapsing improperly, and more
• IE6 does not support min- and max-based CSS properties like min-height, or max-width
• IE6 does not support fixed positioning of background images
• IE6 and IE7 do not support many alternate values for the display property (e.g.inline-table, table-cell, table-row, etc.)
• You cannot use the :hover pseudo-class on any element in IE6 except an anchor (<a>)
• Certain versions of IE have little support for certain CSS selectors (e.g. attribute selectors, child selectors, etc.)
• IE versions 6-8 have little support for CSS3, but there are some workarounds

There are many more bugs, issues, and inconsistencies that can arise in Internet Explorer, but these are probably the most common and most important ones to keep in mind when trying to create a cross-browser experience. I encourage all developers to do further research on many of the issues I’ve mentioned above in order to have a more accurate understanding of what problems these issues can cause, and how to handle them.

Some Things Will Never Look the Same

As already mentioned, creating the exact same experience visually and functionally in every browser is possible, but unlikely. You can get the layout and positioning of elements close to pixel-perfect, but there are some things that are out of the developer’s control.

FORMS WILL OFTEN LOOK DIFFERENT

Discussing all the differences and quirks that occur with form elements across the different browsers and platforms could be an article in itself, so I won’t go into extensive details here. A simple visual demonstration, however, should suffice to get the point across.

Take a look at the image below, which displays the <select> elements on the Facebookhome page, as shown in 5 different browser versions (screenshots taken from Adobe’s Browserlab):

<select> elements appear differently in different browsers

Some form elements can be controlled visually. For example, if the client requires that the submit button looks the same in every browser, that’s no problem, you can just use an image, instead of the default <input type="submit">, which, similar to <select> elements, will look different in different browsers.

But other form elements, like radio buttons, textarea fields, and the aforementioned<select> elements, are impossible to style in a cross-browser fashion without complicating matters using JavaScript plugins (which some developers feel harm the user experience).

TYPOGRAPHY WILL ALWAYS LOOK DIFFERENT

Another area in which we can’t expect pixel-perfect designs is with regards to fonts, particularly fonts on body copy. Different methods have sprung up to help with custom fonts in headers, and the recently launched Google Font API will contribute to this. But body copy will probably always look different in different browsers.

With typography, we not only face the problem of font availability on different machines, but in some cases even when the font is available on two different machines, the type will look different. Windows ClearType, for example, is available on IE7, but not on IE6, causing the same font to look different on two different versions of IE.

The graphic below displays screenshots from A List Apart on IE6 and IE7. The grainy text in IE6 is more evident on the heading than in the body copy, but all text displays a marked difference between the two browsers (unless of course the text is an image):

A List Apart’s typography compared in IE6 and IE7

Use a CSS Reset

Ever since I started using a CSS reset for my projects, my ability to create a cross-browser experience has greatly increased. It’s true that most resets will add unnecessary code to your CSS, but you can always go through and remove any selectors that you know will not be a factor (for example, if you don’t plan to use the <blockquote> tag, then you can remove reference to it, and repeat this for any other unused tags).

Many of the margin- and padding-related differences that occur across different browsers become more normalized (even in troublesome HTML forms) when a CSS reset is implemented. Because the reset causes all elements to start from a zero base, you gain more control over the spacing and alignment of elements because all browsers will begin from the same basic settings.

A CSS reset as shown in Firefox’s developer toolbar

Besides the benefits of producing a cross-browser experience, a reset will also be beneficial because you won’t use as many hacks, your code will be less bloated, and you’ll be much more likely to create maintainable code. I recommend Eric Meyer’s CSS reset, which I’ve been using for quite some time now.

Use SitePoint’s CSS Reference

If you’re having trouble getting a particular CSS property to display correctly across all browsers, look up the property in the SitePoint CSS Reference to see if it has any compatibility limitations. SitePoint’s reference (which is also available as a hard copy, though not as up to date), includes a useful compatibility chart that displays browser support for every standard CSS property.

SitePoint’s Compatibility Charts for CSS Properties

Each compatibility chart is accompanied by a fairly detailed description of the bugs that occur in different browsers, and users are permitted to add comments to document new bugs that come up and to provide further explanations on complex CSS issues.

Using this as a guide, you can narrow down the possibilities, and can usually determine whether or not a CSS issue is due to a browser bug, or due to your own misapplication or misunderstanding of the CSS property in question.

Conclusion

While there is so much more that could be discussed on the topic of cross-browser CSS, the principles and guidelines I’ve introduced here should provide a foundation to assist CSS developers in creating as close to a consistent cross-browser experience as is currently possible. Cross-browser CSS is an attainable goal, within reasonable limits.

But, as an epilogue to this article, I also would like to concur with those promoting the use of CSS3 with progressive enhancement, and encourage developers to push new CSS techniques to the limits, even doing so, where possible, on client projects.

The principles I’ve introduced here should help developers create a beautiful and intuitive experience in IE, while providing an extra-beautiful and super-intuitive experience in the more up-to-date browsers. That’s a cross-browser goal that is definitely worth striving for.

Tags:CSSEssentialsTesting

Guide lines for Browser indepednace.

JavaScript, JQuery and Leading Browsers– behavioural differences

Published November 26, 2011 | By Peter Scargill

Second decade of the 21st century and the browser manufacturers STILL can’t agree on standards.

Here’s a simple piece of coding – almost too simple – it uses the JQUERY library (not shown) to simplify cross-browser coding.

<script language=”javascript”>
function alertMsg()
{
    var gm=”/admin/ajax_keepalive.asp”;
    $.get( gm, function(data) { $(“#myTimer”).html(data); } );
    var t=setTimeout(alertMsg,10000);

}
alertMsg(); </script> 

This simple piece of code works as follows…

The purpose of the code is to put an incrementing number into my web page… that’s all – but the number is coming from another page.. and the purpose of this is to stop session timeouts by making sure that even when the user is idle – something is happening.

The function alertMsg() sets up the address of a web page which returns nothing more than an incrementing number. Every time you call the page, it returns  an incremented number – and the jQuery then forces that number into a SPAN on my web page.  You’ll note that the following line sets a 10 second timeout to call the same routine, over and over.

Finally the routine is called – which puts up the display and sets the timer to call the routine in 10 seconds – ad-infinitum.

Except that it works a treat in Firefox – and doesn’t work at ALL in Internet Explorer. 

There are TWO unrelated issues here – showing the differences between the browsers.

Firstly in Internet Explorer, the routine is never called (alertMsg()) in the first place – because the DOM is not ready when the routine runs – so the timer never gets set.  It would not matter anyway because Internet Explorer CACHES the call to ajax_keepalive() – and so it would  return the same value instead of an incrementing value – EVEN THOUGH calling this page directly in either browser WORKS a TREAT.

Here’s a version that works for both…

<script language=”javascript”>
function alertMsg()
{
var gm=”/admin/ajax_keepalive.asp?r=” + Math.random();
$.get( gm, function(data) { $(“#myTimer”).html(data); } );
var t=setTimeout(alertMsg,10000);

}
$(document).ready(function()
{
alertMsg();
});
</script>

Note that I’ve added a random number onto the end of the page call – as a parameter which never gets used – but it prevents cacheing… also I’ve wrapped the function call in a jQuery document ready function that makes sure this code (AlertMsg()) does not run until the DOM is ready.

Firefox does not need any of this stuff – Internet Explorer does – and we’re not talking old rubbish here – we’re looking at Firefox 7.01 and IE 9 !!!

Javascript Differences in Mozilla Firefox and Internet Explorer

document.all

Internet Explorer 4 introduced the document.all DOM (document object model) to allow access to the various parts of the web page. Soon after that the standard DOM method getElementById was introduced and is therefore available in all version 5+ browsers. This means that the document.all references are only needed to support IE4.

document.all doesn’t work  mozilla why?

Some proprietary document objects such as document.all anddocument.layers are not part of the W3C DOM and are not supported in Mozilla. (There is partial undetectable support for document.all, though, in newer versions of Mozilla. However, that functionality only exists for compatibility with sites authored specifically for IE. You should not rely on Mozilla’s document.all support on new pages.) The methoddocument.getElementById() can be used instead.

In the Standards mode Mozilla does not generate implicit top-level JavaScript variable bindings for elements with the id or name attribute. The correct way to access an element by id is to call the document.getElementById() method with the id as a string as the argument.

Also, old client sniffers can shut out new browsers. The point of having a common API (the W3C DOM) is interoperability, and checking for a particular browser defeats that purpose. When working with the DOM, it is better to check for the existence of the methods and objects you are planning on using. For example, the existence of document.getElementById() can be checked as follows:

if(document.getElementById) {
  /* code that uses document.getElementById() */
}

1. Window/Body OnLoad

When dealing with a site that uses Master Pages, you lose some control, including the ability to declare a page specific event handler. There are ways around this, and I found that the following code example works pretty well.

<script language=”javascript” type=”text/javascript” for=”window” event=”onload“>
    if (document.all)
    {
        initialize();
    }
   else    {
        window.document.addEventListener(“DOMContentLoaded”, initialize, true);
    }
</script>

2. Get Control Inner Text

Retrieving the text of an element is done by using element.innerText in Internet Explorer and element.textContent in Mozilla Firefox.

function getText(control)
{
if (document.all)
    {
return control.innerText;
    }
else
    {
return control.textContent;
    }
}

function setText(control, value)
{
if (document.all)
    {
        control.innerText = value;
    }
else    {
        control.textContent = value;
    }
}

3. Element Height and Width

To retrieve an element’s height and width, use element.currentStyle forInternet Explorer and element.style for Mozilla Firefox.

if (document.all)
{
    top += parseValue(element.currentStyle.borderTopWidth);
    …
}
else{
    top += parseValue(element.style.borderTopWidth);
    …
}

4. Source Elements

To get a reference to the element that fired an event within an event handler, use event.srcElement for Internet Explorer and event.target for Mozilla Firefox.

function getSourceElement(event)
{
if (document.all)
    {
return event.srcElement;
    }
else    {
return event.target;
    }
}

5. Firing Events

You can call fireEvent on an element in Internet Explorer, but it’s more complicated in Mozilla Firefox, requiring an event to be instantiated, initialized, and dispatched.

function fireClickEvent(control)
{
if (document.all)
    {
        control.fireEvent(“onclick”);
    }
else    {
var clickEvent = window.document.createEvent(“MouseEvent“);
        clickEvent.initEvent(“click“, false, true);
        control.dispatchEvent(clickEvent);
    }
}

6. Window Height and Width

Internet Explorer exposes the visible content area dimensions usingdocument.body.offsetHeight and document.body.offsetWidth, whereasMozilla Firefox uses document.body.offsetWidth and window.innerWidth.

function getWindowHeight()
{
if (document.all)
    {
return document.body.offsetHeight;
    }
else
    {
return window.innerHeight;
    }
}

function getWindowWidth()
{
if (document.all)
    {
return document.body.offsetWidth;
    }
else
    {
return window.innerWidth;
    }
}

7. Why doesn’t Mozilla display my alt tooltips?

Contrary to a popular belief stemming from the behavior of a couple browsers running on the Windows platform, alt isn’t an abbreviation for ‘tooltip’ but for ‘alternative’. The value of the alt attribute is a textual replacement for the image and is displayed when the image isn’t.

Mozilla doesn’t display the alt attribute as a tooltip, because it has been observed that doing so encourages authors to misuse the attribute.

• * When the alternative text is shown in a tooltip, some authors write badalt texts, because they intend the text as auxiliary tooltip text and not as a replacement for the image. (‘Bad’ in the sense that the textual alternative is less useful for people who don’t see the image.)
• * When the alternative text is shown in a tooltip, other authors don’t want to supply textual alternatives at all, because they don’t want tooltips to appear. (Again, making things harder for people who don’t see the image.)

There is another attribute that Mozilla shows as a tooltip: title. In fact, the HTML 4.01 specification suggests that the title attribute may be displayed as a tooltip. However, this particular display method is not required and some other browsers show the title attribute in the browser status bar, for example.

At this point some people feel compelled to post a “But IE…” rant in the newsgroups or in Bugzilla. Please note that Mac IE 5 behaves in the same way as Mozilla when it comes to the alt and title attributes. Windows IE also shows the title attribute in a tooltip.

8. Does Mozilla support downloadable fonts?

Downloadable fonts are not supported.

Downloadable fonts are usually used on sites using writing systems for which proper support has been missing in browsers in the past. These sites (for example some Indian sites) code the text in Latin gibberish and then use a font that to the browser and operating system seems to be a Latin font but has eg. Devanagari glyphs, so that when the Latin gibberish is rendered with the font it seems to a human reader to be intelligible text in some language.

Obviously, that kind of ad hockery falls apart when Unicode-savvy browsers come along and render Latin gibberish as Latin gibberish (since that’s what is coded in the file from the Unicode point of view). Instead of providing support for downloadable fonts, Mozilla is addressing the real issue: support for various Unicode ranges.

However, there are still bugs related to support for Indic scripts on some platforms. For example, on Mac OS X Mozilla does not use the Devanagari font that comes with the system but can use a third-party font like TITUS Cyberbit.

A lot of work has been put into Mozilla’s Unicode support. Supporting downloadable fonts in a cross-platform way would also be a lot of work and would potentially require navigating past a bunch of patents but the rewards would be small. For the purpose of rendering non-ISO-8859-1 characters Mozilla already provides Unicode support that, in the long run, is a lot better approach than using pseudo-Latin downloadable fonts separately on each site.

9. In Mozilla Firefox my style sheet doesn’t work! Why?

Here’s the check list:

• 1. Does the HTML document validate? Styling misnested markup may cause strange effects.
  • * The <link> and <style> elements should be inside the <head>element.
• 2. Does the CSS style sheet pass the syntax check? The CSS error handling rules require erroneous parts to be ignored rather than fixed by guessing.
  • * Lengths other than zero should be followed by a proper unit without a space between the number and the unit (eg. 1.2em).
  • * The character to use between the property name and the value is the colon—not the equal sign.
  • * HTML markup, such as <style>, does not belong in .css files.
  • * font-face is not a real CSS property. The property is font-family and @font-face is an at-rule.
  • * If @import is used, it should be the first thing in a CSS file.
  • * In Mozilla 1.8a4 and later (not in Firefox 1.0) CSS parsing errors are reported to the JavaScript console.
• 3. Is the server sending the proper Content-Type header for CSS style sheets?
  • * The correct type is text/css.
  • * In the Standards mode and the Almost Standards mode only style sheets with the correct type are applied.
  • * You can see the HTTP headers sent by the server by using theLiveHTTPHeaders extension or by using the Web sniffer.
• 4. Class names and ids are case-sensitive.
• 5. The element selectors are case-sensitive with XML.
• 6. Style sheet processing instructions are only allowed in the prolog of XML documents. Also, they only work in XML documents—not in documents served as text/html.
• 7. width and height do not apply to non-replaced inline elements such as (by default) <span>.
• 8. text-align: center; centers inline content within a block. It does not (and should not) center the block box itself. A block is centered by setting its margin-left and margin-right to auto and its width to a value that makes the block narrower than its containing block.

It is also possible, although not very likely, that you are seeing a bug.

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

By Scott Gilbertson

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.

Fortunately, for most of your stylesheets, the differences in each browsers’ floating point precision will not result in visible differences on the screens of various devices. However, as Williams’ experiment shows, it’s easy to write a page where those very small differences in rounding become visible when compounded — like a grid-based layout.

What irks Williams and others is that these problems are old and well-known, and yet most browser vendors have still made no move to fix them. Instead, they focus on supporting the shiny new features in CSS 3.

We certainly wouldn’t want to suggest that browsers should stop innovating and supporting the latest and greatest standards-based tools, but sometimes it’s worth postponing playtime with the newest toys to make sure the foundations are solid. In this case, Opera, Safari and Chrome have some cracks showing, and it’s high time they fix them.

Until they do, we suggest you learn to live with the slightly different rendering behaviors in those browsers. After all, pixel-perfect cross-browser support is never going to happen. Given that the web of the future will have even more mobile phones, tablets, and small screen laptops, responsive designs and fluid grids are a trend we expect to grow.

There are also some workarounds. For example, you can use ems instead of percentages, which render much more consistently across browsers. Opera’s Lie also points out that the CSS Working Group has several specifications in draft to address the need for grid-based design, including multi-column text and theCSS Template Layout Module, though neither are widely supported at the moment.

iPad photo by Jim Merithew/Wired