{"id":7,"date":"2010-06-09T16:08:49","date_gmt":"2010-06-09T07:08:49","guid":{"rendered":"http:\/\/santoshkori.com\/blog\/?p=7"},"modified":"2012-03-05T22:56:04","modified_gmt":"2012-03-05T13:56:04","slug":"the-principles-of-cross-browser-css-coding","status":"publish","type":"post","link":"https:\/\/www.santoshkori.com\/blog\/the-principles-of-cross-browser-css-coding\/","title":{"rendered":"The Principles Of Cross-Browser CSS Coding"},"content":{"rendered":"<p>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 <a href=\"http:\/\/dowebsitesneedtolookexactlythesameineverybrowser.com\/\" target=\"_blank\" rel=\"noopener\">gone on record<\/a> as stating that perfect, cross-browser compatibility is not necessary.<!--more--><\/p>\n<p>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 <strong>a near-exact cross-browser experience is attainable<\/strong> 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.<\/p>\n<p>In this article, I\u2019ll be describing what I believe are some of <strong>the most important CSS principles and tips<\/strong> 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.<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" src=\"http:\/\/media.smashingmagazine.com\/cdn_smash\/wp-content\/uploads\/2010\/06\/browsers-css.jpg\" alt=\"Browsers-css in The Principles Of Cross-Browser CSS Coding\" width=\"500\" height=\"500\" title=\"\"><\/p>\n<p>[By the way: The <a href=\"http:\/\/www.smashingmagazine.com\/network-posts\/\" target=\"_blank\" rel=\"noopener\">network tab<\/a> (on the top of the page) is updated several times a day. It features selected articles from the best web design blogs!]<\/p>\n<h3>Understand the CSS Box Model<\/h3>\n<p>This is one of the first things you should be thoroughly familiar with if you want to be able to achieve <strong>cross-browser layouts with very few hacks and workarounds<\/strong>. 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).<\/p>\n<p>The CSS box model is responsible for calculating:<\/p>\n<ul>\n<li>How much space a block-level element takes up<\/li>\n<li>Whether or not borders and\/or margins overlap, or collapse<\/li>\n<li>A box\u2019s dimensions<\/li>\n<li>To some extent, a box\u2019s position relative to other content on the page<\/li>\n<\/ul>\n<p>The CSS box model has the following basic rules:<\/p>\n<ul>\n<li>Block-level elements are essentially rectangular (as are all elements, really)<\/li>\n<li>The dimensions of a block element are calculated by width, height, padding, borders, and margins<\/li>\n<li>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)<\/li>\n<li>If no width is specified, a non-floated box will expand to fit the width of its parent minus padding (more on this later)<\/li>\n<\/ul>\n<p>Some important things to keep in mind for dealing with block-level elements:<\/p>\n<ul>\n<li>If a box has its width set to \u201c100%\u201d, it shouldn\u2019t have any margins, padding, or borders, otherwise it will overflow its parent<\/li>\n<li>Vertically-adjacent margins can cause some <a href=\"http:\/\/reference.sitepoint.com\/css\/collapsingmargins\" target=\"_blank\" rel=\"noopener\">complex collapsing issues<\/a> that may cause layout problems<\/li>\n<li>Elements positioned relatively or absolutely will behave differently, the details of which are extensive and beyond the scope of this article<\/li>\n<\/ul>\n<p><img loading=\"lazy\" decoding=\"async\" src=\"http:\/\/media.smashingmagazine.com\/cdn_smash\/wp-content\/uploads\/2010\/06\/css-box-model.gif\" alt=\"Css-box-model in The Principles Of Cross-Browser CSS Coding\" width=\"500\" height=\"270\" title=\"\"><br \/>\n<strong><em>The box model as its displayed using Firebug in Firefox<\/em><\/strong><\/p>\n<h3>Understand the Difference Between Block and Inline<\/h3>\n<p>For experienced developers, this is another no-brainer. It is, however, another crucial area that, when fully understood, will cause <a href=\"http:\/\/css-tricks.com\/the-css-ah-ha-moment\/\" target=\"_blank\" rel=\"noopener\">the light bulb to appear<\/a>, <strong>many headaches will be avoided<\/strong>, and you\u2019ll feel much more confident in creating cross-browser layouts.<\/p>\n<p>The image below illustrates the difference between block and inline elements:<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" src=\"http:\/\/media.smashingmagazine.com\/cdn_smash\/wp-content\/uploads\/2010\/06\/block-inline.jpg\" alt=\"Block-inline in The Principles Of Cross-Browser CSS Coding\" width=\"500\" height=\"500\" title=\"\"><\/p>\n<p>Here are some basic rules that differentiate block elements from inline:<\/p>\n<ul>\n<li>Block elements will, by default, naturally expand horizontally to fill their parent container, so there\u2019s no need to set a width of \u201c100%\u201d<\/li>\n<li>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)<\/li>\n<li>Inline elements will ignore width or height settings<\/li>\n<li>Inline elements flow with text, and are subject to typographical properties such as <code>white-space<\/code>, <code>font-size<\/code>, and <code>letter-spacing<\/code><\/li>\n<li>Inline elements can be aligned using the <code>vertical-align<\/code> property, but block elements cannot<\/li>\n<li>Inline elements will have some natural space below them in order to accommodate text elements that drop below the line (like the letter \u201cg\u201d)<\/li>\n<li>An inline element will become a block element if it is floated<\/li>\n<\/ul>\n<h3>Understand Floating and Clearing<\/h3>\n<p>For multi-column layouts that are relatively easy to maintain, the best method is to use <a href=\"http:\/\/www.smashingmagazine.com\/2009\/10\/19\/the-mystery-of-css-float-property\/\" target=\"_blank\" rel=\"noopener\">floats<\/a>. Having a <strong>solid understanding of how floats work<\/strong> is, therefore, another important factor in achieving a cross-browser experience.<\/p>\n<p>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.<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" src=\"http:\/\/media.smashingmagazine.com\/cdn_smash\/wp-content\/uploads\/2010\/06\/float-css.jpg\" alt=\"Float-css in The Principles Of Cross-Browser CSS Coding\" width=\"500\" height=\"439\" title=\"\"><\/p>\n<p>Here are some important things to keep in mind when floating and clearing elements:<\/p>\n<ul>\n<li>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\u2019s not floated will appear behind the float in the stack, and any text inside the paragraph (inline level) will flow around the float<\/li>\n<li>To get content to flow around a floated element, it must be either inline or else floated in the same direction<\/li>\n<li>A floated element without a declared width will shrink to the width of its content, so its generally best to have a set width on a float<\/li>\n<li>If a block element contains floated children, it will \u201ccollapse\u201d, <a href=\"http:\/\/www.sitepoint.com\/blogs\/2005\/02\/26\/simple-clearing-of-floats\/\" target=\"_blank\" rel=\"noopener\">requiring a fix<\/a><\/li>\n<li>An element that\u2019s \u201ccleared\u201d will avoid flowing around floated elements above them in the document<\/li>\n<li>An element that\u2019s both cleared and floated will only clear itself of elements that come before, not after<\/li>\n<\/ul>\n<h3>Use Internet Explorer First (Or Don\u2019t)<\/h3>\n<p><strong>Please note that Smashing Magazine\u2019s team strongly advises against developing websites in Internet Explorer first. In our opinion, sites should be developed in \u201cmodern\u201d 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!<\/strong><\/p>\n<p>Most of what I\u2019ve 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 <strong>test your layout in those browsers early<\/strong> in development. You might even want to open up a <a href=\"http:\/\/www.my-debugbar.com\/wiki\/IETester\/HomePage\" target=\"_blank\" rel=\"noopener\">standalone version of IE6 or IE7<\/a> and just start your development in that browser.<\/p>\n<p>Of course, you won\u2019t have access to tools like Firebug, but generally for CSS (especially early in development) you won\u2019t need Firebug. It\u2019s 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:<\/p>\n<ul>\n<li>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<\/li>\n<li>The layout in some spots may have to be reworked, multiplying development time<\/li>\n<li>Testing time will increase, sometimes exponentially, leaving less time for more important tasks<\/li>\n<li>The layout in other browsers will not be the same as in IE6 and IE7<\/li>\n<\/ul>\n<p>I wouldn\u2019t expect developers to use Internet Explorer this aggressively for personal projects, web apps, or other non-client work. But <strong>for corporate clients<\/strong> 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 <strong>cross-browser experience much more likely<\/strong>.<\/p>\n<p>Sometimes viewing IE\u2019s problems as \u201cannoying bugs\u201d 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 \u2014 and build from there.<\/p>\n<h3>Understand Internet Explorer\u2019s Most Common Problems<\/h3>\n<p>If you\u2019re 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 &amp; 7) has problems with, or what its limitations are.<\/p>\n<p>A detailed discussion of every possible problem that can occur in Internet Explorer, and a list of <a href=\"http:\/\/www.smashingmagazine.com\/2009\/10\/14\/css-differences-in-internet-explorer-6-7-and-8\/\" target=\"_blank\" rel=\"noopener\">all of its CSS compatibility issues<\/a> 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\u2019ll need to deal with:<\/p>\n<ul>\n<li>IE6 will become problematic if floats are overused, causing (paradoxically) <a href=\"http:\/\/haslayout.net\/css\/Disappearing-Content-Bug\" target=\"_blank\" rel=\"noopener\">disappearing content<\/a> or <a href=\"http:\/\/www.impressivewebs.com\/ie6-ghost-text-bug-with-multiple-solutions\/\" target=\"_blank\" rel=\"noopener\">duplicate text<\/a><\/li>\n<li>IE6 will double the margin on floated elements on the side that is the same direction as the float; setting <code>display: inline<\/code> will often fix this<\/li>\n<li>In IE6 and IE7, if an element <a href=\"http:\/\/reference.sitepoint.com\/css\/haslayout\" target=\"_blank\" rel=\"noopener\">doesn\u2019t have layout<\/a>, it can cause a number of problems, including backgrounds not showing up, margins collapsing improperly, <a href=\"http:\/\/www.satzansatz.de\/cssd\/onhavinglayout.html\" target=\"_blank\" rel=\"noopener\">and more<\/a><\/li>\n<li>IE6 does not support min- and max-based CSS properties like <code>min-height<\/code>, or <code>max-width<\/code><\/li>\n<li>IE6 does not support fixed positioning of background images<\/li>\n<li>IE6 and IE7 do not support many alternate values for the <code>display<\/code> property (e.g. <code>inline-table<\/code>, <code>table-cell<\/code>, <code>table-row<\/code>, etc.)<\/li>\n<li>You cannot use the <code>:hover<\/code> pseudo-class on any element in IE6 except an anchor (<code>&lt;a&gt;<\/code>)<\/li>\n<li>Certain versions of IE have <a href=\"http:\/\/www.impressivewebs.com\/buggy-css-selectors-cross-browser-jquery\/\" target=\"_blank\" rel=\"noopener\">little support for certain CSS selectors<\/a> (e.g. attribute selectors, child selectors, etc.)<\/li>\n<li>IE versions 6-8 have little support for CSS3, but there are <a href=\"http:\/\/www.smashingmagazine.com\/2010\/04\/28\/css3-solutions-for-internet-explorer\/\" target=\"_blank\" rel=\"noopener\">some workarounds<\/a><\/li>\n<\/ul>\n<p>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 <strong>do further research on many of the issues<\/strong> I\u2019ve mentioned above in order to have a more accurate understanding of what problems these issues can cause, and how to handle them.<\/p>\n<h3>Some Things Will Never Look the Same<\/h3>\n<p>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 <strong>some things that are out of the developer\u2019s control<\/strong>.<\/p>\n<h4>Forms Will Often Look Different<\/h4>\n<p>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\u2019t go into extensive details here. A simple visual demonstration, however, should suffice to get the point across.<\/p>\n<p>Take a look at the image below, which displays the <code>&lt;select&gt;<\/code> elements on the <a href=\"http:\/\/www.facebook.com\/\" target=\"_blank\" rel=\"noopener\">Facebook<\/a> home page, as shown in 5 different browser versions (screenshots taken from <a href=\"https:\/\/browserlab.adobe.com\/\" target=\"_blank\" rel=\"noopener\">Adobe\u2019s Browserlab<\/a>):<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" src=\"http:\/\/media.smashingmagazine.com\/cdn_smash\/wp-content\/uploads\/2010\/06\/forms-browsers.jpg\" alt=\"Forms-browsers in The Principles Of Cross-Browser CSS Coding\" width=\"500\" height=\"331\" title=\"\"><br \/>\n<strong><em><code>&lt;select&gt;<\/code> elements appear differently in different browsers<\/em><\/strong><\/p>\n<p>Some form elements can be controlled visually. For example, if the client requires that the submit button looks the same in every browser, that\u2019s no problem, you can just use an image, instead of the default <code>&lt;input type=\"submit\"&gt;<\/code>, which, similar to <code>&lt;select&gt;<\/code> elements, will look different in different browsers.<\/p>\n<p>But other form elements, like radio buttons, textarea fields, and the aforementioned <code>&lt;select&gt;<\/code> elements, are impossible to style in a cross-browser fashion without complicating matters using <a href=\"http:\/\/widowmaker.kiev.ua\/checkbox\/\" target=\"_blank\" rel=\"noopener\">JavaScript plugins<\/a> (which some developers feel harm the user experience).<\/p>\n<h4>Typography Will Always Look Different<\/h4>\n<p>Another area in which we can\u2019t expect pixel-perfect designs is with regards to fonts, particularly fonts on body copy. <a href=\"http:\/\/www.smashingmagazine.com\/2009\/10\/22\/rich-typography-on-the-web-techniques-and-tools\/\" target=\"_blank\" rel=\"noopener\">Different methods<\/a> have sprung up to help with custom fonts in headers, and the recently launched <a href=\"http:\/\/code.google.com\/apis\/webfonts\/\" target=\"_blank\" rel=\"noopener\">Google Font API<\/a> will contribute to this. But body copy will probably always look different in different browsers.<\/p>\n<p>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. <a href=\"http:\/\/www.microsoft.com\/typography\/cleartype\/tuner\/step1.aspx\" target=\"_blank\" rel=\"noopener\">Windows ClearType<\/a>, for example, is available on IE7, but not on IE6, causing the same font to look different on two different versions of IE.<\/p>\n<p>The graphic below displays screenshots from <a href=\"http:\/\/www.alistapart.com\/\" target=\"_blank\" rel=\"noopener\">A List Apart<\/a> 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):<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" src=\"http:\/\/media.smashingmagazine.com\/cdn_smash\/wp-content\/uploads\/2010\/06\/cleartype-ie.jpg\" alt=\"Cleartype-ie in The Principles Of Cross-Browser CSS Coding\" width=\"500\" height=\"381\" title=\"\"><br \/>\n<strong><em>A List Apart\u2019s typography compared in IE6 and IE7<\/em><\/strong><\/p>\n<h3>Use a CSS Reset<\/h3>\n<p>Ever since I started using a CSS reset for my projects, my <strong>ability to create a cross-browser experience has greatly increased<\/strong>. It\u2019s 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\u2019t plan to use the <code>&lt;blockquote&gt;<\/code> tag, then you can remove reference to it, and repeat this for any other unused tags).<\/p>\n<p>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.<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" src=\"http:\/\/media.smashingmagazine.com\/cdn_smash\/wp-content\/uploads\/2010\/06\/reset-wd.jpg\" alt=\"Reset-wd in The Principles Of Cross-Browser CSS Coding\" width=\"500\" height=\"319\" title=\"\"><br \/>\n<strong><em>A CSS reset as shown in Firefox\u2019s developer toolbar<\/em><\/strong><\/p>\n<p>Besides the benefits of producing a cross-browser experience, a reset will also be beneficial because you won\u2019t use as many hacks, your code will be less bloated, and you\u2019ll be much more likely to create maintainable code. I recommend <a href=\"http:\/\/meyerweb.com\/eric\/tools\/css\/reset\/\" target=\"_blank\" rel=\"noopener\">Eric Meyer\u2019s CSS reset<\/a>, which I\u2019ve been using for quite some time now.<\/p>\n<h3>Use SitePoint\u2019s CSS Reference<\/h3>\n<p>If you\u2019re having trouble getting a particular CSS property to display correctly across all browsers, look up the property in the <a href=\"http:\/\/reference.sitepoint.com\/css\" target=\"_blank\" rel=\"noopener\">SitePoint CSS Reference<\/a> to see if it has any compatibility limitations. SitePoint\u2019s reference (which is also available <a href=\"http:\/\/www.sitepoint.com\/books\/cssref1\/\" target=\"_blank\" rel=\"noopener\">as a hard copy<\/a> (though not as up to date), includes a useful compatibility chart that displays browser support for every standard CSS property.<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" src=\"http:\/\/media.smashingmagazine.com\/cdn_smash\/wp-content\/uploads\/2010\/06\/sitepoint-chart.jpg\" alt=\"Sitepoint-chart in The Principles Of Cross-Browser CSS Coding\" width=\"500\" height=\"127\" title=\"\"><br \/>\n<strong><em>SitePoint\u2019s Compatibility Charts for CSS Properties<\/em><\/strong><\/p>\n<p>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.<\/p>\n<p>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.<\/p>\n<h3>Conclusion<\/h3>\n<p>While there is so much more that could be discussed on the topic of cross-browser CSS, the principles and guidelines I\u2019ve 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.<\/p>\n<p>But, as an epilogue to this article, I also would like to concur with <a href=\"http:\/\/perishablepress.com\/press\/2010\/01\/11\/css3-progressive-enhancement-smart-design\/\" target=\"_blank\" rel=\"noopener\">those promoting the use of CSS3 with progressive enhancement<\/a>, and encourage developers to push new CSS techniques to the limits, even doing so, where possible, on client projects.<\/p>\n<p>The principles I\u2019ve introduced here should help developers create a beautiful and intuitive experience in IE, while providing an <em>extra<\/em>-beautiful and <em>super<\/em>-intuitive experience in the more up-to-date browsers. That\u2019s a cross-browser goal that is definitely worth striving for.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>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 [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[],"class_list":["post-7","post","type-post","status-publish","format-standard","hentry","category-cross-browser-compatibility"],"_links":{"self":[{"href":"https:\/\/www.santoshkori.com\/blog\/wp-json\/wp\/v2\/posts\/7","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.santoshkori.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.santoshkori.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.santoshkori.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.santoshkori.com\/blog\/wp-json\/wp\/v2\/comments?post=7"}],"version-history":[{"count":4,"href":"https:\/\/www.santoshkori.com\/blog\/wp-json\/wp\/v2\/posts\/7\/revisions"}],"predecessor-version":[{"id":9,"href":"https:\/\/www.santoshkori.com\/blog\/wp-json\/wp\/v2\/posts\/7\/revisions\/9"}],"wp:attachment":[{"href":"https:\/\/www.santoshkori.com\/blog\/wp-json\/wp\/v2\/media?parent=7"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.santoshkori.com\/blog\/wp-json\/wp\/v2\/categories?post=7"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.santoshkori.com\/blog\/wp-json\/wp\/v2\/tags?post=7"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}