dbrimlow

Okay, I have finally been convinced of the correct answer to the whole XHTML vs. HTML debate that has been raging for years ... HTML is correct and XHTML is wrong. XHTML may actually become a dinosaur. Here's why. Most of us who thought we were using valid html or xhtml are wrong. Unless you've been using the HTML 4.0 Strict DTD, your code, no matter how well crafted and markup style-free, is NOT valid code ... it "validates" under the Transition DTD, but transitional DTD is not "VALID" HTML. Those of you using HTML transitional, try this. Change transitional to strict. Then test if it is valid at the w3c validation tool. If it validates, get rid of the stupid transitional and keep it as strict. If it doesn't validate, however, promptly remove those cool little "valid html" buttons on the bottom of your page. Now for the real killer. NEITHER XHTML Transitional nor XHTML Strict is valid if it is served using the mime-type "text/html". The w3c says XHTML 1.0 transitional CAN be served with the text/html mime-type, but it is NOT valid XHTML unless it IS served with the "application/xhtml+xml" mime-type. XHTML was abused and never should have had a transitional DTD and it never should have been able to be served under the text/html mime-type. So that brings us back to why I have been converted. I now have to go back to all of those pages that I slaved over for nearly two years, converting from no doctype quirks mode tag-soup to beautifully crafted XHTML transitional - change them all to HTML Strict, re-validate (and subsequently fix) them to be VALID HTML 4.0. Swell, just in time for the new HTML 5.0 and all the debate starting up about THAT!!!

First, unfortunately there is no cross browser support for min-width. Real browsers will obey but, of course, IE thumbs its nose at it. There are a few hacks and bravely tried solutions, but ultimately they don't work as expected. You are not providing the whole problem, though. Although I'm sure others see the same potential problem that I do in the two IDs you did show, a MAJOR cause of most problems are actually not the css, but poorly crafted (or downright wrongly crafted) markup level code and tags. Assuming your markup is correct (a huge assumption without seeing it), the first problem is obvious ... you have a 300px right floated element next to a non-floated, no width specified, 400px margin-right element. But there is clearly something you are leaving out, here, that is allowing #sidebar to act as an absolutely positioned element and "float" over #content_half. Without seeing the markup html and all css, this is impossible to debug with what is shown. CSS is about the "cascading" effect of the styled elements - one directly impacts another and all impact each other. Put one margin 1px over and the whole thing falls like a house of cards. You need to specify a width for both elements and a container that makes them respect the widths.

Because it is a broken tag. The initial p tag is ignored. It is not being seen as a paragraph. You simply cannot imbed nest) block level tags ... they break.

>>et tu brute?<< LOL. Okay, okay. percianno, go to http://www.csszengarden.com and cycle through the layouts there. THIS is the holy grail of PROPER, TM approved, beautiful graphic based designs that you can download and "reverse-engineer" for your own graphics. This will show you how it is done correctly and for the 21st Century. Just pay attention, understand the initial concept and practice. I should have mentioned this in the first place. So, TM ... we cool, now?

Wow. Are you saying that you have clients that use something like "HTML Editor" in their forms - where they enter text and can format font colors headers, bullets and such? If so, you are royally screwdaroo, my friend. If you have no control over the text that is arriving - or the tags included - not only do you have a display issue, but you have potentially serious security problems, as well. These HTML EDITOR JScript programs can be easily hijacked, malicious code inserted and submitted to your server. Again, you can try to get a handle on this via reg expressions and preg_replace. You can create your own functions with reg exp that will search the text for tags and replace those within the file with proper tags that you designate. As a matter of fact, it is pretty common and I was able to find a nice little scheme at the reg exp threads. Mine searches the incoming file for old deprecated tags and replaces them with proper tags. I have it somewhere and will look for it and post it here to give you an example. This will TRULY let you get a handle on your client submissions nightmare. But, there is NO way to sniff for tags using css ... it isn't a "language".

Wait a minute. You can't just leave a string of "text" flappin' in the breeze like that. Text must be put into a proper block level tag. And those ending br tags will cause cross-browser issues (because break tags belong within a line of text .... that's while they are called "break" tags - they provide a forced line break in the middle of text content). Slapping them on at the end of a string of text will cause cross-browser issues (IE 6.0 doesn't always recognize a double br tag as two lines). YOU need to control the content any way you want in your style sheet. First, it KILLS me seeing you use those damn break tags for spacing. Get a handle on your p tags. If they are within a div class, set the p for that class: .offer1 p {margin: 5px 0;} This creates a 5px margin on top and bottom of the paragraph, and zero margin for left and right. I don't know what you have in .marg15, but why not add - font-weight:bold - to it, so you can remove the strong tags in the markup level. Try to style as much as can be done OUTSIDE of the markup. Leave your markup as clean as possible. Let the class or id control it. You will be amazed at how using classes for styling removes hundreds of lines of php code because you don't have to echo the markup styles. I had old php pages that were close to 4000 lines (3,000 of which are old font and table tags to echo!), what a nightmare it was trying to debug, say, an improperly formed table cell from an echo that left out a td tag. Simply create a new class for any text you want to be 15px: .textup {font-size:15px} <div class="offer1"> <p class="marg15"><strong>Description</strong></p> <P>Good looking car. </P> <P>This is a red car.</P> <p class="textup">The car is in working order.</p> </div> Good luck.

The answer is ... there is no easy answer. While I applaud and support TM's good fight against table layout, if you are going to make a website using a huge graphic you may as well use tables and no doctype anyway. The world has passed this type of website goodbye in the last stages of the 20th century.

Sounds either like an IE float issue or a HUGE background image file issue.

Ahh, the old client data entry. As administrator, you DO have control over anything a client does. But it takes a lot of work. Regular Expressions! Thats how I control most of the crap that sits in our database that iss entered by some 18 year old who spends more time talking on the cell phone all day. But, in this specific case, it seems easy. First, code your structure properly: <div class="offer1"> <p class="marg15"> <strong class="gu">Summary</strong> </p> <?=$summary?> <p> <strong class="g">Description</strong> </p> <?=$desc?> </div> Now use a regular expression to check if your variables $summary and $desc have open and closing p tags and if they don't, add them. Unfortunately, my preg skills are not good off the cuff. I suggest going to the reg ex threads here at phpfreaks. Those guys there ARE freaks!

Search engines are about the page content. They determine this by the text the page has. While FP writes garbage code, so long as you have good solid text that describes the service/product/content of the site, then search engines can strip out the garbage, spider the site and index it. But they don't want to work too hard doing so. If a SE bot is having a hard time wading through junk code and all graphics with no actual text ... good bye. And, if the site is about something common, then other better coded websites in the world will rank ahead of yours. The only way for a garbage code site to do better than valid code site is if "quality", "top level" websites link to it. Oh, and the website will only look as you design it in IE. That means 30% of the visitors (Firefox, Mac user with Safari, Netscape, Mozilla, Opera) will see a strange or not working site. This is what your friend meant by proper code. Just be careful and make sure the text of the pages are more important than pretty graphics or cool animation.

You can't nest (embed) block level tags within block level tags. It is bad code. You should also decide if you want xhtml tags or html tags. Since you designate html 4, you should lose the xhtml style break tags (in html br is good enough). Also, get consistent with your tags either uppercase or lowercase (xhtml requires lowercase).

Looks fine to me in both FF and IE 6. It is perfectly valid xhtml and doesn't need any hacks or IE conditional expressions.

You have basic markup level errors. First - You cannot nest a block level html tag within another block level html tag. You are trying to nest list items within a paragraph. Close the paragraph before "Good looking car". Put the sentence after the ul tag in open and closing p tags. Second - you are using an XHTML break tag, yet you are capitalizing some P tags and all list tags. When using XHTML the rule is close all tags and all tags are lower case. Third - using double break tags for line spacing is very sloppy coding. Instead, use p tags and space the margins in your style sheet. Break tags should only be used within block level tags when you want a SINGLE line break and to be followed by text. Never end a paragraph or list item with a break to force a space between two tags - that is a styling issue better handled in your css for that ID or Class p tag.

Yeah, why would you do that? There is a reason people increase their text size and they SPECIFICALLY HAVE TO GO TO THEIR BROWSER AND DO IT. Why would you piss them off by making it impossible for them to read your fixed smaller text? Better your static design blow up, then they not be able to read it.

Try this technique (it may be what you seek). http://www.alistapart.com/articles/prettyaccessibleforms I have never had any trouble adding simple (and reasonable) css styling to forms. I don't try to change the actual browser skin widgets, though.

Oh, yeah, I forgot to mention, AFTER checking your markup for any errors or typos, do the same for your css! You DO have a typo in your css that is hard to see at first. You could have spent hours messing with your css only to discover you miss-spelled padding wrong! ul.menu li a has "paddng-right:1px;" ... should be "padding-right:1px;"

PhotoClickr, you now increased the errors to 38 because you are not closing your tags correctly. XHTML REQUIRES all tags to have an open and close. Stand alone tags like metas, images and break tags close with a forward slash. all meta tags must be closed, like this: you have: should be: <meta name="ROBOTS" content="ALL" /> Your first few tags are right, but then it goes bad. Same with graphics. <a href="http://www.photoclickr.com" alt="online photo services"> should be: <a href="http://www.photoclickr.com" alt="online photo services" />

Whoa! That's NOT even close to a web page! I'm amazed it worked at all in any browser (well except IE). You can't just toss a markup level code out there without even the most minimal of basics and quirks mode html coding structure! An html page (valid or not) contains, at a minimum, an open and closed html tag, head tag and body tag. Without those, it isn't an actual html document and any browser will have to auto-assume that you meant it to be html. And when you ask a browser to assume, forget any possibility that the css will display "as expected", let alone "as coded". When debugging, ALWAYS check for errors in your markup code first! It is WAY easier to fix simple tag errors than unnecessarily messing willy-nilly with a potentially already well planned and coded css, only to discover an hour or two later that the bug was an unclosed li tag - and you now have to put the css back to the way it was originally! So, if your markup is correct, and the css is not displaying "as expected", it is either displaying "as coded", which means you are actually telling it to display that way (though unintentionally), or there is an error in your css "specification structure" (in other words, you broke the rules). That said. Forget what moberemk said. He was assuming that there actually was a css issue (and suggested a sound first stage debug check) Your css will work in FF and IE 6 ... IF YOU USE A VALID XHTML DOCTYPE. But getting back to your structure. At the least, if you use basic, quirks mode (non valid) IE only friendly html structure, there is still no guarantee that your css will display "as expected" across browsers (but in IE it WILL display as "coded"): <html> <head> <title>List item menu test</title> <link rel="stylesheet" type="text/css" href="style.css"> </head> <body> <div id="left"> <ul class="menu"> <li><a class="" href="/index.php">Home</a></li> <li><a class="" href="/link.php">Link Here</a></li> <li><a class="" href="/link.php">Link Here</a></li> <li><a class="" href="/link.php">Link Here</a></li> <li><a class="" href="/link.php">Link Here</a></li> <li><a class="" href="/link.php">Link Here</a></li> <li><a class="" href="/link.php">Link Here</a></li> </ul> </div> </body> </html> However, if you use standards valid doctype code (in your case, since you ended the stylesheet link as XHTML, we will use that doctype (which IE 6.0 at least tries harder to display as "expected" and "coded"): <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> <title>List item menu test</title> <link rel="stylesheet" type="text/css" href="style.css" /> </head> <body> <div id="left"> <ul class="menu"> <li><a class="" href="/index.php">Home</a></li> <li><a class="" href="/link.php">Link Here</a></li> <li><a class="" href="/link.php">Link Here</a></li> <li><a class="" href="/link.php">Link Here</a></li> <li><a class="" href="/link.php">Link Here</a></li> <li><a class="" href="/link.php">Link Here</a></li> <li><a class="" href="/link.php">Link Here</a></li> </ul> </div> </body> </html> CSS can be easy or it can be hard. If you know the rules ... it can be easy; if you don't know the rules ... it can be very hard. Here is a link to the most important site you will ever visit for everything you ever want to know about lists (listomatic tutorials), floats (floatutorial) and, more importantly, everything you MUST know about css rules (selectutorial): http://css.maxdesign.com.au/index.htm Book mark this site and refer to it whenever you have a question about lists, floats or rules. Dave

Yes. So long as you follow the proper rules of form creation, syntax and use proper doctype with valid code and css, form styling can be controlled (there are some cross-browser issues). It is not simple or basic css, though, it is actually quite advanced, but easy to learn. Here is a great article and tutorial for styling all types of form elements - including combo boxes - along with cross-browser fixes. Don't expect to "get it" all in one quick shot, though. Read it through carefully and even copy the sample page code and css for personal styling experimentation: http://www.456bereastreet.com/archive/200410/styling_even_more_form_controls/

Okay, the difference is that DW is for the serious, experienced professional. It is not really for those who want a 100% WYSIWYG type editor. If one just creates pages using design view, it will indeed give bloated code. It makes hand coding zip by. It provides color coded support for php functions, variables, etc. It offers good code de-bugging tools and, for me, who spends nearly 12 hours a day coding, its auto close tag tool and other tools like highlight and click tags, saves me hours in the long run. Most of us who use DW (professionally) code in the "code view" and rarely "code" using design view. It is not a toy for amateurs; it is the best editor for the serious web coder (be it html, xhtml or php). And anyone who publishes their website from within an editor (using its integrated ftp) is foolish. Always use a third party ftp to be sure you replace only the files that you want to. So, that's really the difference. It is NOT for those who are uncomfortable working in code view.

remove "overflow: scroll;" and replace it with "overflow: hidden;"

I have a feeling that your code has been mangled by the forum. Retype the code you want us to look at within the open and close "code" tag it lets you type code in a post here.

You've asked a very important question. Here is an easy to understand link about the whole thing (it is SO worth it to go to this site and learn the basics) bookmark this link - after 3 years, I still occasionally go to it when I get stumped: http://css.maxdesign.com.au/selectutorial/

Glad to have helped. Always glad to see people working at creating proper table-less layout css based valid code. It can be frustrating, but is worth it in the long run. Dave

What I find amazing about expression web (and why I haven't given it any serious thought whatsoever) is because their WEBSITE customer example web sites are nightmares of table based layout and tag soup. Oh, and their css validation showed too many errors to count (while, granted, the html validated). Now, I DO give it credit for being better than FP, but it still creates heavy weight markup pages. I applaud the attempt, but am still quite dubious about it.