I am trying to learn how to create solid layouts with divs and css and trying to move away from tables. I have this site really close. It looks fine in Internet Explorer but its all whacked in Firefox and Im not sure whats causing it. It seems that when i set either a background image or background that the placement doesn't want to show up in the same place and if i put another div inside another one it doesn't seem to want to contain that div inside that one at all. Like hte white backgrounds are not stretching and my bottom footer information isn't working properly either. My site is located at. www.mindimage.net/phelix/tmp If anyone could help me that would be really sweet. Thanks a ton!
Whoever's teaching you CSS is prolly doing it wrong : ) The general rule of thumb is that if everything looks great in IE and fux0r'd in every other browser, then the CSS is totally whacked. IE (esp 6) does so many things wrong that your site can look good in it when it shouldn't. That said, it doesn't really look that bad in FF2 on this machine. Only the sidebar isn't stretching down (and it won't, that's normal). IE6 will take something which is floated and make the container of that float big enough to "wrap" it or contain it. This is against the spec-- all the other browsers will let the float hang out (unless it gets cleared). Usually when going from tables to CSS or just learning CSS you find that you can't make the page the way you really want it. So you fake it. I need to look at thesite again but if that left side is floated like I think it is, you can either put the white background on the container that holds everything (the whole middle part) which means that you'll see white behind the float, or you can do a Faux Column (makes a background image representing what you want and the container holding the float generally gets that as a background image). This means the container needs to stretch to the footer. But containers only stretch to give room to content. They don't go further. So make the footer clear the float(s) and the container will be as long as the longest content while the footer always stays just underneath. Using overflow: hidden will force the container to wrap the float in case the float ends up being the longest thing on the page. Your footer also looks okay... did you want to center it more? (I'm on hubby's Linux machine and don't have IE to look in right now). Cause if the white part of the left menu came down all the way, the footer would only look a little bit too far to the left. The Javascript to change the background image on the menu is slow and bloated : ) The first time I hover over anything, the button's just white until the image is loaded. You can do this with CSS using "CSS Sprites Meets Sliding Doors" (google it!)
i think you need a hack for IE here ... I suggest you to make it on firefox first and then deal on IE later on..
You didn't enclose your float element. Do this: .containtthebottom { /*style.css (line 26)*/ background:#FFFFFF none repeat scroll 0%; margin:0pt auto; overflow:hidden; /*add this*/ width:763px; } Code (markup): It would be a good idea to remove the height property from your elements. Height should not be specified without compelling (and knowledgeable) reason. cheers, gary
As others have said, test against Firefox first and then fix for MSIE later. Also, you need to make sure that your code validates to W3C HTML and CSS specifications. Firefox has a great extension called "Web Developer" that makes validating webpages really easy. IE6 is seriously whacked in regards to its compliance with W3C specifications. IE7 is better, but it still has serious problems.
I generally don't, just because if I don't catch big IE bugs early then it's more work to go back and fix them. I do build my basic page boxes first while looking at FF1.5 but that's cause I'm lazy, not because it's the right way. : )
As someone who has been developing websites for over twelve years, I can assure you that if you do your coding correctly AND validate to W3C HTML/CSS specifications (I use HTML4.01 Strict and CSS2) it will actually be LESS WORK to do development overall if you test to Firefox or Opera FIRST and then test to IE second. If you test for IE and try to fix for Firefox you will be introducing lots more issues to your site because of IE's inappropriate behaviors. A truly lazy individual would find the easiest way to do it right the first time so that they don't have to do more work later fixing things when the browsers change (e.g. IE8 comes out). Anyone who does not have good coding practices now is going to be seriously burned in the future as ALL browsers, including MSIE improve compliance with W3C specifications. Also, you really need to upgrade to Firefox 2.0 until Firefox 3.0 is fully released in a few months. Firefox 1.5 is very out of date and does not support W3C specifications as well as Firefox 2.0 does and Firefox 3.0 supports W3C specifications better than Firefox 2.0 does. Sticking with Firefox 1.5 means you may not be seeing what almost all Firefox users of your site(s) are seeing.
I don't do that either. After making the most basic boxes of a site, I check in ALL (my point was, I don't think it's a good idea to build most of the site for FF or Opera and then check in IE, because some IE bug might mean you need to re-arrange your code to accomodate everyone) browsers. I would never wait so long before also checking and testing in IE as well, was what I meant. And generally, I don't have to change anything around because I'm aware of the bigger bugs as I write. I'm lazy enough to code right the first time AND start off in the wrong browser (1.5) : ) Agreed, but I do also test in FF2 on a windows machine. I tried updating this box to FF2 and Iceweasel and for some reason they both kept rendering as 1.5 (weird). But FF1.5 isn't that different as I compare with FF2, and I've also noticed some sites where FF2 (and other browsers) show everything fine, but 1.5 shows them out of whack a bit. Since I know I can code so that even 1.5 looks good, I keep it around because I figure my code is even more stable if it can accomodate more browsers than just the big 4. When 3 is actually OUT I'll add that to the Windows machine as well. Hopefully I can stop 'Blows from removing FF2 when I do that. The plan in the future is another laptop (this one is getting pretty dim) with Ubuntu and XP still there via VMWare... the Windows part will have all browsers for IE plus Safari, JAWS and Lynx while the Ubunut side has (if I can keep it) the old FF1.5, Konq and anything else that will render different on Unix.
If you do your HTML correctly, you never have to fix your HTML to accommodate IE when testing for Firefox/Opera first. All you have to do is make CSS accommodations for IE. What I do is do my primary site build using Firefox while checking against Opera, Safari and IE. Once things are rendering the same in Firefox, Opera and Safari, I know my code is correct (assuming I've validated it against W3C). If there are still issues with IE then I narrow down why IE has a problem and then throw in version specific IE fixes in the HTML header (<head></head>) using: <!--[if IE 6]><LINK rel="stylesheet" type="text/css" href="/css/IE6.css" media="all"><![endif]--> <!--[if IE 7]><LINK rel="stylesheet" type="text/css" href="/css/IE7.css" media="all"><![endif]--> Code (markup): What this allows me to do is to address version specific IE issues independently. It also means that when IE8 comes out it doesn't get fed IE6 fixes, which might make it choke. Even on my most complex sites, I normally have no more than a dozen IE specific fixes and normally they are just to get pixel perfect rendering that are not absolutely critical (e.g. "line-height" instructions). If you are having serious problems making a webpage work correctly under Firefox/Opera and IE then you really need to look at what you are doing because it is probably a sign of doing something the "hard way". In all of this, the number one most important thing to do is validate to W3C specifications and I strongly encourage the use of HTML4.01 strict and CSS2. validating to HTML4.01 strict, not XHTML specifications and not HTML4.01 transitional is your most assured way of getting things to work on all browsers because HTML4.01 Transitional is too permissive and IE does not support XHTML and instead simply falls int quirks mode (which causes lots of problems when trying to develop a site). And generally, I don't have to change anything around because I'm aware of the bigger bugs as I write. I'm lazy enough to code right the first time AND start off in the wrong browser (1.5) : ) Since it sounds like you are having system problems, I'd recommend waiting until FF3 is released and the remove all traces of FF1.5 before installing FF3. Of course this assumes that the box you are using is not a Win9x box. The plan in the future is another laptop (this one is getting pretty dim) with Ubuntu and XP still there via VMWare... the Windows part will have all browsers for IE plus Safari, JAWS and Lynx while the Ubunut side has (if I can keep it) the old FF1.5, Konq and anything else that will render different on Unix.[/QUOTE] Don't even bother testing for FF1.5 anymore, FF2 should be your base version. FF1.5 only accounts for 2% of Firefox users. Since Firefox accounts for 18% of all users this means that FF1.5 users account for only around 0.36% of all users and their numbers are declining. IE6 is also a safe choice for minimum MSIE support (99.5% of IE users are using IE6 or above). Firefox 1.5 and IE5 are dead browsers, which should be ignored if you want to move forward with development and save development time.
I don't do seperate stylesheets, I just have the few hacks I use sitting normally in the CSS usually. Yeah, my system is screwed, it's a half-working version of Ubuntu Feisty Fawn. I'm guessing that's got something to do with Iceweasel etc acting like 1.5-- it also inherited all my 1.5 tools and extentions, which I didn't want. What I meant about rearranging code is things like, for instance, I was redoing someone's page which was a photographer's so it had a specific design. She had a menu floated on the left and then some containers with various images, background images, etc... and I never found out why exactly but when I started with the first version, I had the floated menu left and the "maincontent" container just sitting alongside it. IE (even 7) did not allow the body of the maincontainer to slide underneath the float, while in all the other browsers it did. I dunno if I still have my copy of that page, but basically I found IE (including 7) counting top margins from the top of the body while modern browsers counted from the bottom of the float (or maybe it was the other way around). Anyway, I'm glad I caught that before doing the rest of the page. I found a set-up (I'd have to look at what I did) which made everyone calculate from the same point. I don't remember if I stuck the floated menu inside the main container or what, but I did have to shuffle the HTML around as far as who contained who. Oh, man, I'm generally very guilty of that! But, I do not have problems getting everyone to play nice (except this current issue I'm having with a footer), so I think I'm doing okay. I've had no problem with XHTML and IE. It's served as text-html anyway... whether one uses XHTML or regular HTML is but a flip of the coin, for all the difference it makes. IE doesn't support XML (or, doesn't support web pages displayed as XML I should say), but my company's new web site is (just because, no good reason) XHTML and works in everyone. If you're curious about the page I'm talking about, I can dig it up. I don't like finding IE doesn't do something and never finding out why, even if I fix the visual problems.
You can still do IE conditional comments and just put style instructions in them instead of a link to external style sheets. I just prefer storing all my CSS in external files. The beauty of conditional comments is that only IE sees them and they are valid HTML because technically they are only comments. Getting the code to validate would help eliminate these types of issues because it would ensure that some stupid coding error isn't causing your problem. Here is the rub, IE DOES NOT support XHTML. Instead, what it does is flip into quirks mode for XHTML and treats XHTML as tag soup. Quirks mode is what causes much of the cross browser issues people experience when developing websites. If you use proper HTML DTDs (e.g. HTML4.01 Strict) you can get IE to flip over to "standards compliant" mode, which while not perfect is much more compatible with other standards compliant browsers (this is especially true with IE7). XHTML and HTML have very different purposes and 99.9% of the time XHTML is not used correctly. One myth is that XHTML will replace HTML. This is not true, they are parallel specifications and HTML5 is current in development along with a parallel XHTML5 (XHTML2 will be DOA).
No, seriously, IE does not go into quirks mode just because you have a page as XHTML. The only reason it ever would is if you also have that "xml prologue" on top, which of course nobody ever does because it's not an XML document, and it's served as text/html. I agree that it's a myth that XHTML will somehow replace HTML. There's pretty much no advantage to XHTML since IE won't do anything with the XML part. A shame. My code is always valid, strict, and no warnings. : )
Again, MSIE does not support XHTML and just treats it like tab soup. Also here is a really good article as to why serving XHTML as text-html is bad: http://www.hixie.ch/advocacy/xhtml There is no reasonable rational for using XHTML instead of HTML if MSIE is to be one of the supported browsers because MSIE does not support the things that XHTML is supposed to offer as an advantage to HTML and XHTML must be served in an in an improper manner if MSIE is going to be able to render the XHTML as a webpage. In short if MSIE is one of your targeted browsers there are no advantages to using XHTML but lots of disadvantages (as outlined in the article I linked to).
Thanks for the link-- it sounds very similar to one I read quite some time ago, by a Finnish dude, with pretty much the same title. I have read it more than once, am aware of well-formed on top of valid, and even go to the point of not having HTML-okay but not XHTML-okay character entities (I use only 4, since apos isn't okay by HTML). But I've found myself doing this with my HTML4 pages as well. Even after reading Korpela (or whoever's) article, it's still coin toss for me which I will use.
All browsers treat html as 'tag soup'. The real concern is the rendering mode, standards, quirks or in-between. Since the xml prologue is optional in xml if the default xml1 and utf-8 are used, and since it is redundant in html, there is no reason to use it and throw IE6 into quirks mode. Hixie's article is a crock. Boiled down, it says if you write invalid markup, and if it gets served up as application/xhtml+xml, it will break. Well, duh! First of all, there is a rationale for using xhtml for all pages. I author documents for a no-IE intranet. We use xhtml and quite often extend the DTD to create specific to the case semantic tags. Yeah, we could use microformats, but microformatting was developed as a work-around to IE's non-support of xhtml. We use the appropriate tool. Since I use xhtml, and since there is no dis-advantage (despite what Ian has said) for general use, I have my main authoring tools, Emacs, Tidy and my brain set up for xhtml. I see no sane reason to alter my configurations of any of them. Serving xhtml as text/html is specifically allowed. It may not be the preferred MIME type, but it is not improper. That said, there isn't any reason for anyone to learn xhtml syntax without purpose, nor is there any reason to stop using it. cheers, gary
And you failed to read the qualifier to my statement. To reiterate what I posted earlier (emphasis added): If you are developing for a non-MSIE environment where you can properly use XHTML (including serving pages up as "application/xhtml+xml") then the use of XHTML is appropriate, but for 99.9% of sites that claim to use XHTML, this is not the case and they are using XHTML inappropriately when they should be using HTML instead.
Yes, I saw your proviso. Like most people, I must support IE the majority of the time. I was pointing out that there is a rationale for using xhtml in the general case, and that there is no reason not to use it. In the general case, there is no compelling reason eschew either of html or xhtml1.0. Write in the dialect you prefer. If you prefer html, fine, but, to reiterate, there is no reason to not use xhtml. (I will agree there is no reason for xhtml1.1.) gary