dbrimlow

I don't see why that wouldn't work. There are also php sniffers for browsers that some people use. But if you do, DON'T use XHTML 1.1, use XHTML 1.0. The W3C says that XHTML 1.1 "SHOULD NOT" be served as "text/html", while XHTML 1.0 "MAY" be served with that mime-type. But the main point is ... why? If you aren't parsing XML then there is no reason to use XHTML in the first place. All it does is serve it using HTML 4.01 specs (with a closing slash for unclosed single elements like breaks, img, hr). In HTML 4.01, you can still use all the same strict coding syntax, well-formedness, lower case, closing paired tags, etc. as XHTML (without the closing slash for unclosed single elements). So what's the point of using XHTML? Like I said, some clients who don't know better, think a coder is more advanced if they use XHTML. When in essence what they are really asking for is standards compliant, valid, clean, uncluttered, non-tag soup, proper semantic structured, non-transitional doctype with CSS styled code. And for that, all that is needed is HTML 4.01 STRICT. Any coder who uses a transitional doctype is either lazy or has a client who insists on features that are not allowed in HTML 4.01 Strict - like "target=", "embed" and other deprecated elements. TM was trying to do the right thing with the mime-type. But he still has validation issues. XHTML 1.1 is really unforgiving. It is a strict doctype by default. And IE will render any XHTML that is not valid as quirks mode. While IE 8 is supposedly going to be 100% Acid tested CSS2 spec compliant, Microsoft has (so far) been avoiding even responding to any questions about whether it will support application/xhtml+xml or not.

This is why using an XHTML is dangerous (particularly XHTML 1.1). you are using the mime-type: <meta http-equiv="Content-Type" content="application/xhtml+xml; charset=iso-8859-1" /> Under no circumstances does any IE understand what that means. I assume you may be using a php browser sniffer for IE? To change the mime-type to "text/html" for IE? Still doesn't work. You have some serious errors in the mime-type (could be the server is not configured to serve "application/xhtml+xml"). It is auto defaulting to "text/html" and causing invalidation. Also, your form fields are not valid - particularly for any strict doctype which xhtml 1.1 is. Fieldsets, legends, select and input elements can be styled (somewhat) when semantically wrapped in a logical block level element ... like paragraph, header, list. Here is an example from a site of mine using a valid xhtml1.0 strict ("text/html") doctype (some customers want to see XHTML thinking it means we are better coders, so give it to them, but serve it as text/html and ALWAYS XHTML 1.0): <ul> <li> <fieldset> <legend>AREA</legend> <select name="sect" size="1" id="label"> <option value="ALL" selected="selected">All Areas</option> <option value="UPPER EASTSIDE">Upper East Side</option> <option value="UPPER WESTSIDE">Upper West Side</option> <option value="DOWNTOWN">Downtown</option> <option value="MIDTOWN EAST">Midtown East</option> <option value="MIDTOWN WEST">Midtown West</option> <option value="UPPER MANHATTAN">Upper Manhattan</option> </select> </fieldset> </li> </ul> But get a handle on your doctype and validation. If it is invalid, you can't trust any cross-browser compatibility.

try this: .textlink a:link, .textlink a:visited {font-weight:bold;color:#FF0000;font-size:14px;}

Your structure needs to be contained within a regular column-like format. You need to remove the floats and put the login and title blocks into a left column "wrap" . Remove the floats for the "Register" block and put it into a "right" column wrap. Something like this: Tweak widths to suit. But bronzemonkey's right, without seeing how you code the blocks (using lists, headers, etc) it is impossible to really help.

This is something everyone who creates websites should know and do. Putting "Hacks" in the main css to make IE behave is no longer recommended (due to IE7 and the pending IE8 ignoring the old hacks). Now using "IEOnly".css files is easy and clean thanks to the "Conditional Comment" zang8027 showed: <!--[if gte IE 5]><link rel="stylesheet" media="screen" href="css/IE5GTE.css" type="text/css" /><![endif]--> You will want to change this to exclude IE8 - which should be css2 spec standards compliant, I recommend changing gte to lt (less than) IE7: <!--[if lt IE 7]><link rel="stylesheet" media="screen" href="css/IE5GTE.css" type="text/css" /><![endif]--> They key to using the IEOnly.css file via the "conditional comment", is that the ONLY thing in the IEonly .css file you have to change are the bits of elements that need to be different in IE. In other words, you don't need to copy the whole element from the main css file. Usually it is only margins/paddings or widths/heights that need tweaking in IE. Examples: Main css file would have: #wrapper { width: 800px; margin: 0 auto; margin-top:5px; background: #ffffff url(images/wrapper_bg.png) top left repeat-y; } IE only css file fixes the margin problem for IE: #wrapper {margin: -17px auto} IE still uses the main css element's width, background and margin-top, but only changes the margin from "0 auto" to "-17px auto".

If you haven't designed your site to look good in 1280 x 1040 widescreen format than it isn't as simple as you think. TM's sites are a perfect example of a sites that would scale well. They are clean and uncluttered. But few of us have clients that allow us to dictate plenty of white-space. If you are used to pixel-perfect alignment of everything, then a liquid layout is not simple to scale. But, if you use graphics or photos, then I suggest that you actually design your site on a widescreen laptop first.

Sorry, bro, but FF in Ubuntu was a whole different thing from FF Win/SuSe/Mac. It unequivocally handled floats and width percentage vs. font-size relativity differently than the others. I had to uninstall it on that server because we needed a back-up exchange server in an emergency, but I am getting a new server to install it on and will upload screenshots ... the whole IT team of our office was amazed since we've used SuSe and RedHat for years with no appreciable difference from FF win and didn't think an OS could implement a browser any differently. A practice everyone should do. Particularly with what we now know about the proposed IE8. Actually, think about it for a minute, N. (This is one of the few things that I took time to understand the whys and hows) The reason is because while IE7 fixed the 1% bug , AND properly ignores the * html selector, it still does NOT recognize the :after pseudo element. So UNLIKE modern browsers, which use the clearfix method centered around the :after to auto-clear our floats, IE7 will NOT auto-clear based on the :after. Apparently setting a min-height on the container in IE7 expands the container the way setting height in IE6 does. The :first-child + html is necessary for targeting only IE7. So in my IE only css file I can use them both ... hmmm, unless this is what you mean by you don't have to "target it" which you would if it was in the general css. Is it because it is in the IEonly css that simply applying * + html {min-height:1px} works?

I never noticed the full extent of the float clearing problem until I saw my sites on FF in Ubuntu. I had always checked my betas in: WinXP/IE5.5, IE6, FF, Opera, Mac/Safari, IE5.03 SuSeLinux/FF, Sea Monkey But once I saw what Ubuntu did to my main site's homepage I realized that I was ignoring a fundamental of floats because I had previously not seen the problem in all the browser/platforms above. bronzemonkey elects to not use the :first-child pseudo element in the IE7 haslayout fix because he hasn't "seen" a need for it. But I learned my lesson thanks to Ubuntu. If the prevailing wisdom says it should be ... I will believe them before I believe my lyin' eyes. By the way ... finally being able to completely ignore IE/Mac and IE5.5/Win is one of the most satisfying events in my 12 year career! But this shows me that IE6 will hang on for a good 5 more years at least.

Exactly, just like all other form elements. And this isn't only a "modern browsers vs. IE" thing. This problem tends to range across browser AND platform. I assume its because form elements are controlled using defaults of the browser AND OS skin. There are some things you can style. And I've been able to get legend somewhat under control lately using different stylesheets. Today, more than ever with the beta release of IE8, it behooves everyone who uses css to create their own IE management stylesheets. Thanks to conditional comments, this is so much easier than the old IE/Opera hacks littering your css. Here is a good link to a form styling article and example that does at least help manage styling some of the things that can be styled - A List Apart - Prettier Accessible Forms This has helped save my job (my firm's managers and CEO only use IE and were getting tired of hearing me tell them why I couldn't/wouldn't do things that they saw our HACK IEonly competitors doing - the fact we beat them in SEO cuts me only so much slack). Dave

haku is 100% (1em, 16px) correct. You can't just slap ems in place of px and expect your site to work as originally intended. The whole point is that ems are relative! They are not a fixed unit of measure on their own. They need an initial reference in the body tag. For modern browsers you can set the initial body font-size to pixels and ems will work relative to the px. However, but of course, this is not the case for IE. IE can't calculate relative sizing when the body uses a fixed (px) font-size. And as Anzeo said, the general default font-size for most browsers is 16px. But trying to calculate the relative em of 16px is a nightmare. If 1em = 16px, (which is too large for most of us to use as a default) then 1.1em would be 17.6px ... YIKES!! You would be forever just guessing and trying different size combinations all under 1em to equal 12px or 10px. .9em or .8em or even .75em? Marko Dugonjić, however, came up with both a simple solution and a web tool to help you calculate the relevant sizing. Here is the concept: base-font-size He bases it all on body {font-size:10px) for modern browsers and font-size:62.5% for IE. That way 1em = 10px, 1.2em = 12px, 2em = 20px, .9em = 9px. Now, that said - as is so often the case with css - "it isn't as simple as that". Because the font-size is not forever and globally relative to the declared body font size; it is relative to its parent element. So, unless you are an advanced mathematician, once you declare a font size for a container other than 1em, all elements within that container become relative to the new font-size. Imagine what can happen if you nest a few containers within each other but not adjust the font-sizes? Well, like I said, Marco came up with a tool called typetester that does the math for you. Some people love it. I don't have the time to play with it yet so I don't know how easy it is to work with ... I'm sure it works fine because a lot of serious pros have linked to it in their books (although I notice they don't use it). I personally just set my body font-size to "small" and have created my own visual cues for relative em sizing from there.

Its called a "liquid" layout (as opposed to a "fixed" layout. It can be done. But it is extremely advanced unless you are keeping your pages simple. You will need to use "relative" dimensions sizes (like percentage or EMs) instead of pixels.

This always happens. BUT, it is best for the person who started the thread. It shows that the issue is not a simple one and has deep layers. And, if the solution they go with starts to blow up once adding other data and page content, they don't get as frustrated because they know it is most likely a float issue. Since you're not a newbie at html, it shouldn't be as daunting as it could be beginners. You will eventually run into float clearing trouble if you don't use a fix. Good luck. Dave

Well, now you heard it from THE MAN who knows, and tipped off a lot of us here about the ease of the clearfix variation (also mentioned in Dan Cederholm's "Bulletproof Web Design"). And while I've also had success leaving off the :first-child pseudo element for the IE7 HasLayout fix (after seeing that it worked without it), I don't take chances that it might be necessary for certain situations ... it doesn't hurt to leave it in. Absolutely! I constantly (almost daily) have situations (usually a bordered box with an image and text floated to its left) where before entering the clearfix, IE6/WinXP will clear the floats while FF doesn't. It is the one situation where it seems as if IE6 got something right that FF didn't. Unlike many pros who can find the time to study the whys and hows, I am coding 12 hours a day, 5 days a week and need to take advantage of the academics of it all that's been done by others ... I simply need the results to work so I can apply it fast and move on to the next project I'm given by "the powers that be". But the main problem with the state of css and browsers today is that it is NOT an exact science. Each browser interprets the CSS2 Specs differently (some closer to others). And the whole issue of this thread comes down to cross-browser/platform compatibility. If you work using mainly one platform and one browser - Windows OS/IE, Mac/Safari or Linux/Sea Monkey or whatever - than you will have to know what the fixes are for the other browser/platform combos. The one I found to really get the css2 specs right is Ubuntu Linux/FF 3.0. I would like to see the acid test results for that.

Opera is strange (I don't know about versions other than 6.0). Sometimes it was compliant, but other times it was as funky as IE. For the MOST part it displayed similar to modern browsers. AND, like IE, it was fine with poor quirks mode code, but once you had valid html/css it could get wonky. So not having seen the newest version, I can't really comment. I just had a few issues with Opera 6.0. There is nothing more sobering than to see your perfect web page in FF 3 for Ubuntu Linux! They really got it right ... ands it blows up uncleared floats like nobody's business! Actually, haku, like I said, we use a variation of the clearfix. It does not involve any extra markup whatsover (or even inline class). It is done by applying the fix (the ":after" pseudo element) directly in the css, like so: .floated1:after, .anotherfloat:after { content:"."; display:block; visibility:hidden; height: 0; font-size: 0; line-height: 0; clear: both;} Some add the "HasLayout" fix in their css like this: .floated1:after, .anotherfloat:after { content:"."; display:block; visibility:hidden; height: 0; font-size: 0; line-height: 0; clear: both;} /* for ie 6 only */ * html .floated1 {height:1%} /* for ie 7 only */ * :first-child + html .floated1 {min-height:1px} But that causes css to not validate. So most put these into an ie-only.css file that is called using a conditional comment in the head tag, like this: <!--[if lt ie 7]><link href="../css/ie-only.css" rel="stylesheet" type="text/css" /><![endif]--> But simply using "clear:both" in the select element's css does not work. It works occasionally if you are lucky and not floating block level elements between non-floated elements. But once you drop a floated element between a non-floated element you can try clear:both all you want, but it still will not clear - and if you didn't instruct IE 6 to use * html height:1% and IE 7 to use * :first-child + html min-height:1px, then your floats will do strange things in IE.

I'm really glad you didn't take offense. It was totally not my intent and what worried me right from the start was that people were trying (with good intent) to give advice on your exiting code which just wouldn't work. Also, your comment about FF and "DIVS" showed that you are testing in IE in the first place. No one can ever expect to be cross-browser compliant if they FIRST test their code in IE. While FF has some faults (most particularly, and coincidentally enough, with float clearing), it is a "Modern" browser (along with Safari, Mozilla, Netscape, Sea Monkey and sometimes Opera) and will behave like one. Floats are rough enough to master. They take a lot of trial and error. One thing to remember about floats is it is usually best to float side by side containers left (instead of one left and one right). Also, it is best to use percentage widths instead of fixed widths. Particularly if you are working within a fixed main page wrap. But there are two absolutely crucial things to learn about floats - simply applying clear:both within a css select element will not help.: 1. clearing them properly - most pros concerned with cross-browser have used a variation of the "clearfix" technique (which seems hard to understand at first, but miraculous once mastered). The original version of clearfix Although, apparently there is a newer, much simpler method (which I haven't had time to test, yet) here, simple clearing 2. Dealing with IE's "HasLayout" - warning - heavy reading written in "geekese" Sometimes I wish I could go back to the simple days of table layout, but once you see your css based layout work you'll never go back.

I don't want to come off too negative, here, but why are people throwing out advice when the basic concept and structure is seriously flawed in the first place? There is so much wrong with just this simple example that when actual content is added it will just get worse. I assume you are using a DOCTYPE and CHARSET in you head tag (and know what they are). A line break tag "br/" is NOT a styling device to create margins or paddings. It is MEANT to be used to force a line break WITHIN a paragraph, list, header or other proper "logical block level element" used for containing text. This is just wrong: <table class="check3infotable"> <tr> <td> </td> r</tr> </table> What is the "r" doing outside any table tag (even a wrong one). All data in a table goes within a "td" tag ("d" for data). You are using your floats wrong in the first place and certainly not clearing them properly. You have to understand the complexity of properly floating elements before just slapping them on the page as if the were table cells and expect them to work as such. And I hope the table that is in these elements are for "tabular" data and not as yet more "styling" design aids. Because then the whole point of using "divs" and css "selects" is totally moot. You need to brush up on your basics. Here is a link of a few great quick tutorials on the basics of css including: 1. how to use floats (floatutorial) 2. The most important aspects of css structure (selectutorial) 3. and everyone's favorite ways to make menus with lists (listomatic) maxdesign Good luck. Once you learn all the concepts you can begin to code for cross-browser compliance. The key is to code it to work in FF first, THAN look at it in IE (so you can tweak a few elements and using a conditional comment toss them into an IEonly.css file to force the IEs to behave as it should) ??? :o Where could you POSSIBLY have read that? At a Microsoft sponsored blog? Or from the code view challenged "gurus" at the Dreamweaver "support" forums? A "DIV" is nothing but an html markup level placeholder! Period. It has nothing to do with CSS, browsers or browser interpretation. It is what it is ... and empty container waiting for some data to contain. The same way a paragraph tag or table tag is just an html data placeholder element. It is only when YOU tell it how to behave by inputting style commands within a css select element that browsers pay attention ... and IE has ADD, not FF. IE 5.x3, IE 5.5, IE 6, IE 7 (AND now even the beta version of IE 8!) all display CSS differently and not according to any understandable conception of the W3C web standards for CSS 2. And NO IE version can even display XHTML when it is properly (as intended) served as "application/xhtml+xml". Only when served as "text/html" (which therefore renders it as if it were html 4.01) can IE handle it. If you want to create web pages, NEVER even view them in IE until they are finished and working as intended in FF. The see how IE6 and IE7 messed up the css so you can make a few easy qucik tweaks to make them behave.

True, for those who know what they are doing. But, Dare87 was riding the ol' newbie frustration train ("I have been working on it for the last few hours"). So I shot him off the quick fix. I would also assume he isn't using proper semantic coding and drops text naked into DIVs as if the were "logical block level html tags". He'll learn. Meanwhile we sometimes try to help erase the mind-numbing frustrations first.

The quick way is to add your style "inline" ... like this: <ul> <li class="sideBarTitle" style="font: 12px Verdana, Arial, Helvetica, sans-serif; border-bottom: 1px solid #000000">Main</li> <li><a href="index.php">Home</a></li> <li><a href="applications.php">Applications</a></li> <li><a href="download_2003.php">Demo Spreadsheet</a></li> <li class="sideBarTitle"><a href="ss_solutions.php">Spreadsheet</a></li> <li><a href="uc.php">Discussion</a></li> <li><a href="ss_consultation.php">Consultation</a></li> <li><a href="ss_development.php">Development</a></li> <li class="sideBarTitle" style="font: 12px Verdana, Arial, Helvetica, sans-serif; border-bottom: 1px solid #000000"><a href="acad_solutions.php">AutoCAD</a></li> <li><a href="uc.php">Discussion</a></li> <li><a href="uc.php">Consultation</a></li> <li><a href="uc.php">Development</a></li> <span id="sideBarTitle" style="font: 12px Verdana, Arial, Helvetica, sans-serif; border-bottom: 1px solid #000000"><a href="prgm_solutions.php">Programmables</a></span> <li><a href="uc.php">Discussion</a></li> <li><a href="uc.php">Consultation</a></li> <li><a href="uc.php">Development</a></li> <li class="sideBarTitle" style="font: 12px Verdana, Arial, Helvetica, sans-serif; border-bottom: 1px solid #000000">Info</li> <li><a href="testimonials.php">Testimonials</a></li> <li><a href="contact.php">Contact Us</a></li> </ul>

You DON'T want the margin move 12px you want 12px of padding. Margin makes the whole box move ... no the contents. Try padding:15px. Also, avoid using "position:absolute" at all costs unless you really know what you are doing. Unless your container with the background image is designated as "position:relative", your text as "position:absolute" takes it out of the flow of html altogether. (which would by default move it to the top left of the browser's window).

First, IE6 does not support transparent pngs ... only gifs. Second, your navigation stability depends upon a lot of other factors (not only for IE): 1. what is your default font-size (fixed or scalable), 2. what are the default margins/paddings for your lists (ul, ol, dl and li), if you don't designate the margins/paddings for any list you are leaving it up to the browser to do it automatically. That means it will most likely look different from browser to browser. To see why you are having trouble, remove the background images and designate a background color (like light background-color:#FFFFCC) for #navigation. Now look at it in FF and IE. Ie6 is using its auto-margin/padding for the ul. Also, when using "scalable" font sizing it is advisable to use scalable margins/paddings for your containers as well. And did you clear your float?

Anything that gets displayed by a browser can be looked at and copied ... it is why it is called "browser side". You shouldn't worry about people stealing your css or html. a: I personally consider it flattering. b. I never leave my css or html alone for more than a few months anyway. There is always a way to improve it, new and better techniques are always coming out, converting pages from transition doctypes to strict and making older markup semantic, and of course, 99% of every web page can always be optimized for true accessibility (which is real a bitch to do!).

It sounds to me like you need to use a cobination of "faux columns" and "sliding doors" techniques. These use simple gif images that are larger than the dimensions of the element for which they are the background ... this allows them to expand and contract along with the flexible content of the container element. It is a way to appear as if you have more than one background graphic in a single container element. I know you said the height isn't fixed, but Is the width fixed or percentage? Dan Cederholm's "faux columns" technique is a very cool way of creating a flexible percentage width graphic (which borrows a little from the Doug Bowman's "sliding doors" technique). faux columns sliding doors

This is the beginner to css's best resource (many of us pros still bookmark it): The venerable max design "selectutorial" This will teach you the most important basic rules of css in a clear, concise and palatable way. It is crucial to know this first in order to avoid massive frustration later trying to figure out why your css element isn't working. And while you are there, the listomatics, listutorial and floatutorial are also must visits. Bookmark it! You will come back to it often while learning.

The techniques for tiling small graphics to emulate borders is by making them background images for combined (nested) elements. The best technique for getting horizontal rounded corners starts with the "sliding-doors" technique. Once you get your head around the concept, it works for everything. 100% liquid/elastic and fluid. http://www.alistapart.com/articles/slidingdoors/ When used in combination with a small gif for vertical tiling (repeat-y), it can appear like one fluid box - resizable both ways and elastic as well (when text is browser resized).

Yeah, IE6 is dodgy when trying to match colors with images .. and most particularly with png images! Even simple web colors can not match an image using the same colors. I've had many frustrating hours due to this. Try converting the img to jpg (and only use it in IE6) - that's worked for me 80% of the time.