Hello there I would like to ask you what general approaches you know to carry out the task of adapting the css which works well for firefox, to make it work the same in explorer or other particular browsers which might raise problems. For example, if you take a glance to (I hope it is not forbidden to mention website with learning purposes) www.metatradersoftware.com, you will be able to realize that the language flag on the upper right side is lower or higher positioned depending on whether the browser you use is explorer 6 or firefox. So far, the only solution I have heard to avoid these discrepancies is building another css style sheet with the slight modifications required for explorer and importing only the one associated to the corresponding browser. Nevertheless, I would appreciate if anybody could tell me the code I have to put to distinguish which browser is being used among the common different explorers. That would let me carry on with this strategy. Moreover, if you know another techniques which might be better for this purpose than having several css style sheets and importing the corresponding one to the browser used, I am willing to hear about them as well. Thanks in advance.
Well, from your tone it sounds to me like you've already made the mistake - of completing style sheets and layouts BEFORE testing in IE. That right there is usually the road to /FAIL/ and the 'fix' is going to be throwing it all out and starting over from scratch. Why do I say this? Because the best approach is to code your CSS in small blocks section by section testing in each browser as you go - NOT just firefox, but also Opera, Safari and of course IE... and bare minimum I would test both IE6 & 7... and with care, IE 5.5 and 5.2 can be just as easily handled. The first step for any layout - at least in my book, is to get all your content on the page with semantic markup. Give NO concern for appearance as if you have appearance in your HTML, you've defeated the entire point of even HAVING CSS. Then and only then do you use CSS to bend that HTML to your will, adding one, maybe two DIV's you didn't think of ahead of time. (in my case that's usually #container and #contentWrapper - see http://battletech.hopto.org/html_tutorials/3coldiv/template.html for pages that show both in use) If you code to only one browser - doesn't matter which, it is just as likely you are relying on bugs or incorrect behavior of that one browser as you are valid markup or behaviors. Firefox (despite many of the more rabid FLOSS zealots know-nothing rantings) does NOT get it 'all correct'... NO browser does. Relying on any one browser for testing is therin shortsighted, lazy and just plain asking for headaches by wasting time on something you might not even be able to deploy. That said, there are only a handful of major shortcomings that 'need' workarounds for IE. double margin IE doesn't like margins on floats and insists on doubling their size. The solution is to set display:inline on the floating element which trips lord knows what in IE that makes it not do that... since floats are inherently display:block the display:inline has no effect in other browsers. Borders+Padding+Width This is only really a concern on IE 5.x which is 'always' in quirks mode, because it doesn't know what standards are. In 'quirks' mode the only major thing you'll hit up against is the IE box model, which says width means the outer edge of the border, not the inner edge of the padding. If you declare "Width:200px; padding:16px; border:16px solid #000;" in 'quirks' mode the distance from the outer left edge of the border to the outer right edge will be 200px - in standards compliant browsers you'll get 264px between the two. The solution to this 'problem' is to just get in the habit of never declaring a width the same time as paddings or borders. MOST of the time you can get around that fairly easily and it does give one advantage - less math in your head. LI behavior IE flat out HATES styling LI. Usually if you are floating anchors inside LI, you are best off just setting the LI to display:inline then pretending they don't even exist in your markup. This is not an option for dropdown menus though, so you end up having to play with things a bit to get it exactly right. Usually the LI problem can be most easily seen in IE7 where a set of floats will 'staircase' across the screen. Double Render and Dissapearing Content If you've never heard of this one, the first time you encounter it you'll rip out your hair, then rip the skin off your skull, then pick away at the bits of bone until you hit brain tissue - which you'll then give the 'Dave Test' to like it was a pack of Scotties. The cause of this bug? Comments. HTML Comments... Specifically, putting HTML comments BETWEEN floats. If you have: <div id="sideBar"> Some content </div><!-- end #sideBar --> <div id="adBar"> Code (markup): Where both #sideBar and #adBar are floating, there is a chance the content of #sideBar might not fully show up on the page, or worse will render in two different locations on the page! This is why 'traditional' commenting techniques need a bit of revision. (Oh, and 'end?' - DUH, I had no clue what </div> means!) The solution? Put the comment BEFORE the closing tag. <div id="sideBar"> Some content <!-- #sideBar --></div> <div id="adBar"> Code (markup): BTW, for information on good coding habits, you should read: http://www.ibm.com/developerworks/linux/library/l-clear-code/ haslayout Back in the day when CPU horsepower was at a premium Microsoft decided to 'short-circuit evaluate' the rendering of all elements putting less calculations into elements they figured wouldn't need the extra math (and cpu time) spent on it. A lot of people TODAY badmouth the practice, but it really is one of the things that made IE so much faster than everything else, and why it was the first 'modern' brower to end up being practical on mobile hardware under winCE. Because of this though a number of CSS properties (which were introduced later) will go ignored, get miscalculated, or not update if the page layout shifts or you manipulate position in javascript. To get them to render properly you have to 'trick' IE into classifying them as 'having layout'. Figuring out if haslayout is the problem in a mis-render is mostly blind luck - though setting it is easy enough. If an element has a declared width or height, it automatically 'haslayout'. You can 'abuse' this by setting a percentage height, like 'height:1%' to trip haslayout. This only works though if overflow isn't set to hidden or auto. It says right in the CSS specs that a percentage height on an overflow:visible element is changed to auto if the PARENT element has no height declared on it. Because of that though, there are times you cannot use height:1%; to trip it. In those cases you can use zoom:1; to trip it - but be warned that in doing so your CSS will not validate. There are other ways of tripping it, but frankly they generally have even bigger issues than the two I just listed, so I'd not even bother with them. -------------------------------------------- Now, that's not all of them, but those are the 'big ones'. That said there are some other tips and tricks that make cross-browser coding simpler NULL YOUR MARGINS AND PADDING The quick version of * {margin:0; padding:0;} is great so long as you aren't dealing with forms... There are more 'complex' resets out there that I find a bit wasteful - one of the problems with frameworks is they most always include code you'll never use or need. When setting all values with * is an issue, I use JUST the following: html,body,address,blockquote,div, h1,h2,h3,h4,h5,h6, hr,ul,li,menu,ol,ul, table,tr,td,th,p,img { margin:0; padding:0; } img { border:0; } Code (markup): I've NEVER needed more than that. Hell, the only element that REALLY gives me fits having it's margin/padding nulled is a damned INPUT[submit]. Don't trust the default line-height!!! The HTML specification effectively says 'somewhere between 110% and 120%' - Opera, Safari and IE all default to 120%, though IE and Opera discard fractions, Safari rounds off... Firefox seems to randomly use anywhere from 110% to 130% depending on the font, and ALWAYS keeps track of ALL fractions across lines, meaning if you have four lines of 130% in a row, the fourth line will be one pixel taller! This brings us to: Remember rounding differences Firefux also does this 'oddball' floating point math on width calculations, which is why centered or right aligned backgrounds often end up with a 1 pixel jog as the screen width changes. This limitation also makes doing 100% min-height layouts in firefux a royal pain in the ass unless you make the footer be a pixel height. (and therin make the fonts a pixel height). It keeps track of all fractions applying them 'as needed' meaning you cannot ever rely on a pt or %/em calculation being the same on the same page twice in a row. Opera has a similar issue that makes doing a float stack tricky - it throws away fractions of a percent... If you declare width:99.5% in Opera, you will only get 99%. Forms - the ultimate nightmare The specifications do not clearly state how form elements should be rendered, so, as Dan Schulz once said to me "The browser makers all did what they do best - went their own directions and to hell with what anyone else is doing." For MOST form elements that contain text, input[text], input[password], etc, IE treats line-height as Gecko treats height - so setting both the same will usually get you the same result. The exception to this is input[submit] which seems to have it's own special rules in every browser (except opera). When it comes to padding, Firefox seems to have 2px top and bottom and about 3-4px on the sides (depending on the font so it's likely a fraction of a EM) that you have no control over. IE likewise has HUGE padding of which there's no control at all... Safari - well, safari doesn't want inputs to look like anyone else's approach and uses the goof assed OSX widgets meaning no chance in hell of predictably controlling their placement - particularly the extra width their goofy rounded corners require... Only one browser seems to have done the sensible thing IMHO - In Opera all form elements are simply inline-block level elements and formatted as such. ***SHOCK*** What a concept. (it really is the most sensible approach in my mind - why complicate things by using a different codebase to render what can be done the same way?) Avoid "Gee ain't it neat" Eye candy bullshit - AJAX for tabs without new pageloads, javascripted menus, bloated menus that use conditional comments for each menu item in the markup, flash for static images or goofy animations - all of it results in bloated rubbish that not only makes the page slow to load, look like crap for people who browse with plugins disabled (like me), but it also is more garbage to try to sift through should there actually be something wrong. -------------------------------------------------------- Some other advice would be to maintain good coding habits - adopt or create your own style guide and stick to it, modifying it as you go to fit your needs. For example, this is the most recent version of my style guide, which all of my code follows: http://battletech.hopto.org/html_tutorials/styleGuide.txt Consistancy of your code, good indenting and coding habits, proper breaking up of elements and blocks can speed your finding bugs, solving layout issues, and can even prevent you from making stupid mistakes like failing to close a tag in the first place. It also means when you ask for help, other people will be less lost. On the subject of not 'losing' other developers when asking for help - LANDS SAKE use classnames that are not cryptic and actually mean something - and do NOT use presentational classnames. If you have a class for bold, a class for italic, a class for float:left - what the devil is the difference between that and inlining the styling in the first place? Completely defeats the point of separating presentation from content and in fact the point of even using CSS. At that point, you might as well go back to using HTML 3. It's like these retards that put all their CSS on one line - I've rarely seen that done where the same property wasn't declared multiple times, conflicting and legacy properties stacked up, or just plain invalid CSS was present that you couldn't even see. All of that plays into the most important aspect of cross-browser coding. If you are stuck and your google-fu fails you - ASK. There is nothing wrong with asking a question you don't know the answer to - and keep in mind it is VERY unlikely you are attempting anything that hasn't already been tried, and even more important if someone in the know says "That's not worth the effort" or "Throw it out and start over" - LISTEN.
Damn Jason, he wasn't asking you to write the frakking Web Design Bible! (And yes thosecars82, I am the person that deathshadow mentioned when he was telling you about how browser vendors decided to handle forms.)
Yeah, well, he did a better job of it than most of the "name" players who've made big bucks with their books and appearance fees. cheers, gary
You'll have to ask him that. Right now I'm focusing on getting the site's informatin architecture audit done (it's almost complete). Then I'm going to hire a designer to create a design for it, and then we'll be launching the site.
Actually, i was thinking somewhat the opposite. A nice design with only the minimum of code necessary to pull it off. You know, to show what's really possible.
Heh, the Minimal Markup Zen Garden : ) If my "design" skills or creativity were better, I'd offer to do it for free, but not sure I could make a nice WOW! design.
If I ever have the time to WRITE a better version of this (I started to do so, have the first two 'parts' of four completed)... Though much of it is in my 'draft' notebook. I just write down my observations and ideas in dead tree edition as they come to me - then type them in when someone asks a question like this. Right now I've got one client I'm struggling to finish off before I start another client monday (assuming they contact me today about the proposal and signing a contract). Never seem to have time to work on my own stuff these days. (much less the pages I volunteer on for other people) - end of the day it's about keeping a roof over the head and food on the table. Of course, Dan and I are working in parallel on our own sites on the subject of minimalist semantic markup.
Thanks a lot deathshadow, I really appreciate this great explanation. And I do not mind that it is a long response, I mean, it is even better bearing in mind that I am introducing myself to this world of webdesign and wanna learn as much as possible. As everybody knows, there are good and bad ways to achieve the same. Above all, I want to learn good standards to do things well from the beginning. Thanks again.