Is relative positioning the ultimate alternative for the nightmare of writing thousands of IE hacks? - css

I found this very interesting:
http://matthewjamestaylor.com/blog/ultimate-3-column-holy-grail-pixels.htm
He avoid using horizontal margin and paddings to avoid problems with IE. I think he "fakes" padding using relative positioning.
Have you ever done something like this?
I'm a missing a common trend against IE hacks?
Does this practice have any drawbacks?

That example is outdated.
Problems with margins and paddings like that were a problem with the broken box model of IE5. In later versions of IE you will only get that broken box model if IE is in quirks mode. That's something you should be avoiding at all cost. Use the right doctype!
The example you linked actually relies on that broken box model. He has an updated version that doesn't:
http://matthewjamestaylor.com/blog/holy-grail-no-quirks-mode.htm
But what kind of IE problems are you actually trying to address? Do you specifically want a 3-column layout like in the page you linked to? Do you want general solutions for IE layout problems? Or do you want to be able to forget about IE altogether?
The most important thing to know about when dealing with layout and IE6/7 is its hasLayout property. Read On having layout for all the details on that.
If you are specifically looking for tools that can help you build complex layouts compatible with all browsers, you could have a look at grid frameworks like YUI Grids or Blueprint. But I can't say I'm a fan of those, since they tend to result in unsemantic div soup.
If you don't mind a little (experimental) JavaScript to fix up your entire website automagically, you could give IE7.js a try. I've used this, though it definitely has its quirks and limitations, so use at your own risk.
To come back to your original question, though, relative positioning is no ultimate solution for anything, it's just one of the tools in the box. Understand it and use it when it's appropriate. See, for example, Sitepoint's CSS layout and formatting reference. And as dry as it may be, I find the CSS specification to be invaluable, especially the chapters on the visual formatting model details.

Related

Best practice for CSS3 backgrounds and support for older browsers?

My colleague and I are having a tough time deciding on a best practices approach for ie6, ie7 support for a site we're building. The site is for an older crowd, so not supporting these browsers is out of the question.
At the same time, we're trying to start incorporating modern coding practices into our work so we can get practice and fully understand capabilities. A specific area I want to touch on with you guys is handling fall backs for CSS3 backgrounds.
We have 2 choices here, if we're to use CSS3 backgrounds and not add extraneous wrapping tags for backgrounds:
Use :after, :before etc. pseudo elements for adding multiple backgrounds to elements. (this is the choice we've made for now)
Use CSS3 multiple background specifications
This produces more elegant markup and is certainly a step in the right direction. But what about browsers that don't support these features?
Modernizr.js tells us to check for specific support and then write fallbacks:
Modernizr.load({
test: Modernizr.geolocation,
yep : 'geo.js',
nope: 'geo-polyfill.js'
});
However, we're not given much guidance on the actual fallbacks for specific features. So, in the case of something like CSS3 backgrounds, what would be an effective fallback strategy?
Would we (for example) use jQuery to wrap those extra tags we need (ie btn-container, nav-container, etc.) around nav items, buttons and containers in order to have extra elements to add style attributes to?
About the CSS3 multiple backgounds and/or background gradients I think there is an approach better than those you proposed: CSS3 Pie.
This way you will be able to use all those nice effects also in IE6, 7 and 8 (including also border-radious) without any JavaScript intervention.
1. Fail gracefully. Certain complex elements can be hidden with CSS and revealed upon page-load with JavaScript depending on the browser as one example.
2. Conditional style-sheets or JavaScript fixes. Spend a lot of time fixing each problem in each browser and write a style-sheet just for it. Also, you could try various JavaScripts that claim to bring older browsers into compliance. I've tried this JavaScript but it seemed to conflict with jQuery. CSS Pie is another option to bring rounded corners to older browsers.
3. Ignore older browsers. Do nothing special for older browsers. People on IE6/7 already see the world differently than everyone else. Alternatively, do nothing special for older browsers but actively avoid overly complex functions & features. Optionally, you can add a nifty "upgrade notification" message with little effort.
Would we (for example) use jQuery to wrap those extra tags we need (ie btn-container, nav-container, etc.) around nav items, buttons and containers in order to have extra elements to add style attributes to?
That is certainly one valid fallback approach. Depending on the design and the elements in question, though, you might find that simply supplying the primary background is enough to yield a decent-looking and perfectly functional, though not visually identical, component.
"Supporting" older browsers shouldn't always mean "taking great pains/writing tons of extra code to insure a near visual match." It is difficult but not impossible to ramp up a QA team so that they understand the concept of Progressive Enhancement as it can be applied to aspects of pure visual presentation.

Experimental CSS for IE: To hack or not to hack?

There are some eye-candy experimental CSS like border-radius (rounded corners) and gradients that I wish to use on my page. Unfortunately Internet Explorer does not support any of that yet. At least border-radius is coming on IE9, no word on gradients yet.
So would you recommend just leaving IE alone (most of my users will be on FF or Chrome anyways) or use images to "fix" the presentation for IE? Is it even worth it? Because I know that not only is a pain in the behind but might also break styling on other browsers.
So, to hack or not to hack?
Although this question is a bit subjective, my answer would be not to hack. CSS3 was made to be backwards compatible, and that means it will degrade gracefully if a browser doesn't support it. That for me is the way it should be. I mean, why use CSS3 if you're still planning to hack it anyway? In that case just use the plain old CSS2 tricks like javascript rounded corners or images so you do't have to hack per se.
Terminology quibble: using images to imitate CSS3 features in IE isn’t really hacking. Any visual effect that isn’t directly supported in CSS will need to be implemented in images.
But to answer your question, it depends:
If few enough of your audience use IE, then you can ignore it. Figuring out how few is few enough is up to you/the site owners.
If not:
If the border-radius effects aren’t a key part of the site’s branding, then I’d suggest you just let IE ignore them and use square corners. No-one browses the web with two browsers simultaneously, and no-one cares if your site looks a little bit different in IE 6, as long as the buttons are in the same place and everything works.
If they are a key part of the site’s branding, or your client insists on the site looking the same in IE 6, then you’ve got to achieve the look in IE 6. So, either:
use border-radius, and use conditional comments to include a stylesheet for IE 8 and below with code to imitate the features
don’t bother with border-radius — use the code that works in IE for all browsers. This will avoid you having to maintain two sets of code, but it will mean that all browsers have to download the images you’re using for IE, thus making them perform slightly less well.
I don't think its ever a choice between 'hacking' and not implementing it at all across all browsers, and I'm surprised nobody has mentioned one of the real life-saving 'feature' (I won't consider it a hack, since it is a brilliant method for backward compatibility): Conditional Comments
Not only does it help with annoying IE bugs, it also allows you to define less desirable, but still 100% valid methods for getting certain effects to work, like image gradients with repeat-y instead of CSS3 gradients, or tiled semi-transparent pngs for IE7 and 8. Really, if you want to, IE shouldn't be the one single factor that will limit your ability to experiment with CSS3.
if you do not want images, IE hacks or a seperate stylesheet you could always check out CSS3Pie: http://css3pie.com/. It's not perfect, especially not when you want some gradients & shadows but it can deal with rounded corners pretty easily. There are similar IE behaviors out there but I think this one has the most active development at the moment.
There are hacks and then there are hacks. I interpret a "hack" as being something that exploits a flaw in the browser, such as the descendant selector hack in IE (using >). Those types of things break when the browser is updated.
I don't consider using images to create nice drop shadows or gradients to be a hack. It may not satisfy the requirements that you are doing everything semantically, and you may feel queasy about resorting to using an image for something that an image should not be required for, but the reality is that there's simply no choice - no way to do everything the clean, no-images way - if you want pretty gradients and shadows on the majority of people's browsers (Internet Explorer being that majority).
If you consider the rounded borders or gradients to be just optional eye-candy then by all means don't worry about IE. But if you consider that it actually does make your design look good and you don't want the majority of your users* to miss out, then go for it.
*Depending on your audience, IE may or may not make up a majority of your audience I guess.
That really depends on how important those features are to the look and feel of the site, or rather how important the client and design team feel they are. Additionally its a quation of how much is this going to bloat your markup and CSS - ie. depending on how the effects need to be built in the context of the design how much of a hassle is it going to be?
Normally in this case im in favor of progressive enhancment, ie. come up with something suitable but it doesnt need to be a 1-to-1 to the composite art. Again though, this is a decision you as a developer will ever really be in a position to make on your own (well, unless youre also the designer).

Are there some good CSS practices in order to avoid browser-compatibility issues with IE?

I've discover so far that:
stating the width in some elements fix issues in IE.
and of course using a CSS reset
Do you know any others?
Learn about hasLayout
Inline block behavior can be achieved on IE7 by turning on hasLayout, then setting display to inline. This has turned out to be quite useful to me.
Make sure your doctype is present and correct. This alone can save hours of pain.
Use conditional comments anytime you need to hack something especially for IE. PLEASE don't fall into the amateur's habit of adding star/underscore junk in your main stylesheet.
I'd say that manually setting width would more often than not break things in IE, as a lot of IE versions implement a flawed box model.
I'd also say that a lot of all browser incompatibilities originate from a sub par understanding of the box model and float/clear, block/inline.
Having said that, I of course do not deny that it is IE, rather than the developer, that is the real problem, but I usually seek to avoid browser incompatibilities by using HTML structures that not even IE could miss-interpret, rather than through CSS hacks, and I've found that that is often quite doable.

Re-learning CSS the right way [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 2 years ago.
Improve this question
I am a programmer doing web development for over two years now. Even though I’ve been doing front end engineering for the past two years I don’t think I have done it the right way
For instance:
I still do layout with tables and not with just CSS. I haven’t still found out a way to correctly present data aligned and tabular.
I don’t know the difference between display: none and visibility: hidden (well, I know it now. but there are many cases like- padding, margins, overflows etc)
I haven’t really followed the inheritance way to writing CSS. Almost every style starts with a # and not a class.
Whenever a page loads slowly the html elements are out of place and fall into order only when it’s completely loaded.
I don’t know what this picture in firebug is conveying (by the way, firebug is my savior. Life would have been impossible without Firebug)
Whenever layout’s in a mess I am tempted to use position:absolute. Invariably it ends up in a bigger mess.
I know I am doing a lot of things wrong(and I need to get it right) here but I manage to get things into place and somehow show it up, only to see it messed up in a different browser.
I don’t want do a primer on CSS or CSS for dummies. I know more than that. I want to learn CSS the right way. Focusing on problems like the examples I showed above and rectifying them.
Can you point me to resources or add common suggestions and tips used by CSS developers to get it right.
Check out Designing With Web Standards by Jeffrey Zeldman.
Here are some general rules to live by:
Tables are good for tabular data. If the data you're presenting belongs in a table, don't go out of your way trying to make a grid out of <div>s. Doesn't make sense.
As far as layout is concerned, use <div> tags, stay away from tables. Get to know the float property well. With CSS3, there are going to be new, improve standards to the display property. Learn them.
display: none completely removes the element from the viewport. Conversely, visibility: hidden retains the whitespace that the element would have otherwise taken up. In both cases, the element remains in the DOM.
General rule of classes and IDs. Page elements and IDs should have a one-to-one relationship per page. For example, #Column1, #Column2, #Footer, #Header. Page elements and classes, on the other hand, should be a many-to-one relationship, like: .container or .navLink. Use classes when you know you're going to be using a particular element quite a bit.
Think in terms of efficiency. The less style rules you have, the more quickly your page will load and the easier style issues will be to debug.
I have about a million other things to say but that should get you started.
For layout-driven CSS, be sure to check out Everything You Know About CSS Is Wrong. It's a bit cutting edge, since IE 7 doesn't support display: table (pity, I know), but it does cover traditional layout CSS techniques like floating and absolute positioning, and provides a good transition from table-based layouts to CSS ones. I highly recommend it.
I don't know if you're building off of any dynamic language or if you're just coding raw HTML, but you should also look at using SASS in your projects, as I think it helps force you to pay more attention to inheritance. Otherwise, reviewing more "rudimentary" tutorials (like CSS for Dummies) might actually be helpful, as they go over a lot of CSS's fundamental principals in detail.
Lastly, CSS works best when you have semantically correct (x)html underneath the hood. In my opinion, it's easiest to see and learn "good" CSS when you have great, semantically correct html underneath. Here's a good overview of when to use what tags. Generally, I find it best to write my content with no regard what-so-ever to how it will look later, then use CSS later to make it gorgeous.
As always, you can pick up lots of neat tips and tricks at CSS Tricks, which have always helped me learn more about the correct usage of the language (like when I learned about overflow: auto for contained floating elements! Genius!).
Hope that helps!
Visit CSS Zen Garden to see what you can do only with CSS.
Visit W3 schools and follow the tutorial. It might seem simple for you, but you will learn the basic stuff.
Visit some sites, such as A list Apart to see how to do things and learn tricks.
See if a CSS framework suits your needs (such as 960 Grid).
I'm assuming you've installed Firebug?
Also, http://www.doctype.com might get more relevant results.
Practice, practice, practice. You know what you don't know, and that is the key to success in my mind. Every project you do, try to improve your skills, and eventually it will become second nature to do it the right way.
Eric Meyer's Cascading Style Sheets 2.0 Programmer's Reference is a great resource to understand exactly how selectors and rules work, and serves as a great reference as well.
Some thoughts on what you posted.
A Master Reset style sheet will
help with browser differences.
And Tabular data should use tables.
It's layouts that should avoid table
tags in favor of css.
Plenty of people here give good advices. I'll just add two more:
First, try to write valid (X)HTML. You can easily test your HTML code using W3C's HTML validator. Focus mainly on content, not on style.
Second, try to write valid CSS, preferably in a separate .css file. Avoid using the style attribute. (This part can be hard, if you want to support certain old browsers from Redmond). You can test your CSS using W3C's CSS validator.
Read CSS: The Definitive Guide by Eric Meyer. He explains why CSS was created, how it works (according to the standards), and will give you the background to understand the finer points. It also makes a good reference.
Experiment in Firebug
I don’t know what this picture in
firebug is conveying
Firebug itself can help you there. Do this:
Create a div with some text in it.
Use CSS to give it padding: 5px; margin: 5px; border: 1px solid black;
Examine it in Firebug, as you show in your question.
Click on any one of those numbers in the box model it's showing you, and start pressing the up and down arrows (or type a different number).
See how it changes in real time? This is one of the best things about Firebug: it lets you tweak without reloading, then modify your stylesheet when it looks right.
Keep doing this until you understand how padding, margins, and border work.
I think you should use, for your layout needs, one of the so called "css frameworks" (960.gs for example).
They are fast and reliable enough to build cross-browser layouts and also easy to read and understand as well, so you can learn all the good practices while you are coding.
CSS are easy and aren't a real programming language: don't be afraid of the word "framework" ;)
You could start by reading some good books on the matter. The ones of Eric Meyer are hands on and of very high quality. The other book that of which I learned a lot was the Zen of CSS design book.
And the rest is effort and practice. Be sure that you understand why something works the way it does, don't be satisfied with 'trial-and-error' css development.
http://www.amazon.com/Zen-CSS-Design-Visual-Enlightenment/dp/0321303474/ref=sr_1_1?ie=UTF8&s=books&qid=1255629419&sr=8-1
http://www.amazon.com/More-Eric-Meyer-Voices-Matter/dp/0735714258/ref=sr_1_1?ie=UTF8&s=books&qid=1255629449&sr=8-1
http://www.amazon.com/Eric-Meyer-CSS-Mastering-Language/dp/073571245X/ref=sr_1_1?ie=UTF8&s=books&qid=1255629462&sr=8-1
Well, I will address some of these issues as best I can.
The difference between display:none and visibility:hidden is when the display is set the space for that item is not reserved. So imagine it as when the display is set the item is 'gone' off the page. Whereas if you are using the visibility option, the elements are on the page, in their place just invisible. Did I explain that clearly? Hopefully, that makes sense for you.
As far as the padding, border and margins, this is all referred to as the CSS Box Model. The information is contained as the element, its padding, border, then its margins. So padding is the distance between the element's content and its border whereas the margin is the distance between the border and the neighboring element. Again, I hope this helps clear this up for you a little bit.
Transitioning to CSS is sometimes tricky but well worth it.
Well the basics are quite simple, you should really get a hang of the quite easy if you've already don't some css coding.
The best practices, browser quirks, hacks and other sketchy stuff concerning crossbrowser layout is something else.
Here is my suggested reading list, all of them are on my bookshelf and certainly worth reading! If you ask me i'd say these are the book you should have read if you are a webdesigner.
Designing with webstandards
CSS Mastery
Bulletproof webdesign
for me, Pro CSS and HTML Design Patterns by Michael Bowers changed it all. no more endless trial-and-error, but problem - pattern - solution. indispensable.
Whenever a page loads slowly the html elements are out of place and fall into order only when it’s completely loaded.
Are you putting your stylesheets at the top, in the <head> section?
Are you declaring explicit sizes for images, or does the browser have to guess, then rearrange things when the image shows up?
Depending on your learning style, I might recommend going straight to the source: the definition of CSS. You can find each of the various specs here: http://www.w3.org/Style/CSS/. While the specification doesn't really cover specific browser quirks (if it did, they wouldn't be quirks, would they?), it does a really good job (for me) of explaining how each piece works.
I will tell you my secret: follow this two classic tutorials
Listutorial
Floatutorial
And you'll know 80% of what you need to know about CSS.
30 Websites to follow if you’re into Web Development
http://htmldog.com/ is, in my opinion, one of the definitive resources to learning front-end web development the proper way.

Is CSS layout really as delicate as it seems to be?

I have been experimenting with the Majestic template at freecsstemplates.org. So far so good; I really like the look (or to be more specific, my boss really likes the look).
However, I am noticing that the CSS that drives this template seems very brittle; small changes can cause really radical breakage. In particular, if I reduce the size of the header in the CSS (to eliminate some of the empty space at the top of the page), both of the outside columns suddenly disappear.
With small websites, sometimes I cry uncle and just use tables for layout. I realize this is heretical; should I be leaving the design to the professional designers? Or maybe I'm going about this the wrong way, and someone can set me straight.
I honestly think this layout has been made pretty badly. The width of the elements seems to change where they appear on the page, and they're all need to be pixel perfect for everything to be centred.
For some bizarre reason the whole page has been placed inside the div element marked 'header'... This doesn't make much semantic sense for a start.
However, it seems if you decrease the width of every element which has one, then everything does get smaller, and nothing should disappear.
I would recommend looking at some other more sensible layouts, since I don't think this is a very good way of attaining that style -- as you've said, it's brittle. Have you tried using the extension Firebug for firefox? It allows you to make on-the-fly changes to the css, and see how it affects the style, which will help you learn fast.
CSS is delicate, but still easier to deal with than a site full of table layouts. I found Dave Shea's book CSS ZenGarden to be a great help in learning CSS from a designers perspective.
Often in layered templates there are a few places where changes to CSS can be made, and it can be really confusing to follow which selectors are controlling the element you wish to manage. There are many tools out there that can help, but some that have been useful to me are:
Google Chrome and its Inspect Element option
Selector Gadget - a bookmarklet that will help you visually determine the selectors that affect an element
Firefox's Web Developer plug in
One other tip is to learn about the !important modifier - it can come in handy to force a particular property setting when there are multiple CSS selectors affecting the same element.
CSS in my experience is easy to understand in concept, but takes a long time to master.
Brittle CSS can be very brittle, but good CSS can be wonderfully flexible.
As it stands CSS can either make layouts wonderfully simple and flexible or it can make the simplest of tasks an absolute nightmare.
Purists will tell you to use CSS no matter what, a pragmatist will tell you to use what works. If using a table or non-CSS solution makes something infinitely easier to do, then use it!
Personally I try to use pure CSS as much as possible, but there have been times when I want to do nothing but swear when something glorious in FireFox looks awful in IE. This is where the hacks come in. It is these hacks and work arounds that tend to make CSS brittle in the first place.
Half the problems with CSS would go away if all the browsers did precisely what the CSS spec says they should do. Alas, this is yet to happen so we have to live with either using tables, or on occassion, brittle CSS.
The best solution is to make the design as simple as possible. If you find you have a hundred divs and lots of CSS trickery to do something straight-forward, stop. Re-think how you are approaching it and try again.
At the end of the day your website users don't really give a monkeys what your website looks like as long as they can get at the information they want with minimum effort. Successfully manage that and they will not care how photorealistic that shiny nav bar is, or how well the borders line up etc.
That's my 18pence at any rate :)
I agree most css template is hard to read, and different people may have a very different approach to the same layout strategy. Since there are too many hacks/tricks/techniques in css it is really fragile when you try to modify those existing one since almost all cases, the styles are very dependent to each other.
Css doesn't break as long as you don't break it ;) It's a language. Just like a regular one, if you don't use proper grammar people won't understand what your saying.
If a layout doesn't work or suddenly your page looks rubbish, I'll guarantee you it's your fault. Css isn't brittle, the code you wrote with it might be.
So start by learning the basics and don't just dive into some file you found online which might (in your case, does) contain very bad code.
If you end up wanting to use tables for everything may I suggest you start looking at some grid systems like http://960.gs/ and ease your pain.
Gideon

Resources