I have been trying to systematically unlearn and clean up bad habits from when I learned to build sites ~7 years ago. Right now I'm trying to make sure that my HTML and CSS validate, which they do, but it breaks things. First I'll spell out the problem, then give more info about the site.
Exhibit A is here: http://pc247h8312.med.unc.edu/ccbc/index.cgi
This main page does not supply a DOCTYPE, yet it works better than the other pages. In Windows using IE6, The page looks precisely the way I intend. There are no margins at the top or left, the images all line up, and there is a darker blue margin to the right and left of the navigation buttons on the side. In Linux using Mozilla 1.4.1, there is an anooying offset of one pixel that causes the ccbc logo to not line up. Works well in Windows, slightly broken in Linux, but fails validation because there is no DOCTYPE.
Exhibit B is here: http://pc247h8312.med.unc.edu/ccbc/microarray/index.cgi
The rest of the pages in the site use a common header, so they all supply a DOCTYPE. In Linux/Mozilla, the pages look identical to the home page: in other words, there is an annoying 1 pixel offset. In Windows/IE6, the lighter blue navigation buttons have no right margin and go right off the side of the lefthand column. This page validates, but does not look the way I intend.
Answers to the following three questions would make my day:
1) why does adding the <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> declaration cause the navigation to break in Windows? (The css element is .navigation and it is pretty far down in the css)
2) Why is the logo offset and rather crappy looking in Mozilla?
3) Why are the bottom borders of the last three navigation buttons colored differently than the top ones in Windows but not in Mozilla?
If I can in any way assist you with answering these questions, or if there is a basic resource I can use to find the answer, let me know. Thanks. More info below.
It is a dynamic site where each page is created in .cgi. There's a .txt file called ccbctop.txt and one called ccbcbottom.txt. the cgi pages read the contents of ccbctop.txt and print them, then print their own html/database results/etc, then read and print ccbcbottom.txt
Pseudocode:
#!/usr/bin/perl
read and print top.txt
insert individual page stuff
read and print bottom.txt
This way I can change the layout of all pages by changing two text files. The code is written in Perl against a mySQL database. For an example of a dynamic page, visit exhibit B above, click RNA quality check, and use the login JDoe and no password.
~~~~~~~~~~~~~~~~~~~~~~~
Currently seeking a technology analyst/instructor/web developer position in the research triangle, any tips appreciated!
If you get the pages working OK in other browsers but it falls apart in IE/Win when you add a DOCTYPE then it is down to IE crappy support for standards - basically it goes into quirks mode. I ran into the same problem over the GN.
Before those questions can really be answered, there are a lot of things in the code that need addressing.
1) You should always have your doctype in place while designing/developing. That way there are no suprises when you add it. The doctype tells the browser how to interpret your code, based on the definition provided in the doctype declaration via the url.
One thing I would recommend is using strict rather than transitional. Why? It tells the browser to stick to the standards. It makes it easier to be sure things work the way they should.
2) Using tables for layout in this case is *totally* unneccesary and is simply bad practice. This would be one of those old bad habits
3) you vary a great deal in the way you use quotation marks in your tags. ANywhere you have a this="that", the "that" should be in quotes. You also should be using your CSS, preferably in an external stlyesheet (as opposed to using style="...") to specify the height/width/border of your boxes.
4) <font> tags
The logo: the image is actually 101 pixels tall, yet in the HTML you specify it as 100px. I have to assume that is part of the problem. The <p> wrapped around can't help matters much either, nor can the fact that the background image is 150px.
Getting all that straightened out should help matters..
What??? You discovered my table hack??? Don't worry, I know I don't need tables. However, until I learn how to not use them, it stays. But thanks for pointing it out.
I don't understand what is wrong with FONT tags. I see people slam them but I don't get it the same way I get tables=bad.
I will change the doctype to strict, thanks for that tip.
My once over to check for unquoted tags obviously didn't catch them all.
The embedded style elements will go into the external style sheet. I'm placing them in the code on purpose for the moment because it is easier to tweak the elements to see what works. However, external vs embedded is not a functional difference, and it does not explain why the elements are shifting. However, I will do that and see if it triggers the root of the problem.
The <font> tag is a purely stylistic tag. It is a deprecated element (meaning the w3c themsleves say 'don't use this anymore').
The idea of markup is to be a structural guideline for the interpreter (browser in this case) to follow. Certain heirarchies are formed, and different types of data get marked appropriately.
Stylistic issues should be left to the CSS. That's what CSS is for.
The whole idea is to seperate the style from the content (and the structure). It's not a matter of "slamming" the font tag - the font tag is simply a very bad way of going about things. You've already got the <h1> tag there - style it with CSS. Forget the <i> tag and the <font> tag. That's just useless markup that clutters the structure of your page.
As for the embedded vs. external styles - that's jsut another example of keeping your style and structure seperated. Assigning a class is a very valid structural enhancement. It tells the browser that the element in question has specific purpose. The CSS is there to define how that purpose is differentiated visually.
I have made many of the changes that you all brought to my attention.
GOOD NEWS:
No more tables!
Many (not all) of the embedded style elements have been moved to the stylesheet.
The height for the logo has been properly set to 101 px.
BAD NEWS:
I can't figure out how to position the elements properly.
There is a blue line under the nav bar where the background is peeking through.
The top bar plants itself over the corner logo.
The text wraps around the sidebar because i'm using float.
Font tags still need to be replaced.
I have searched the style sheet reference site that I'm using to learn this stuff, but I cannot understand how to position the elements to look how I want it. Any pointers appreciated.
The problems you're having are not all that bad. I don't have time just now to go through it all (I'm at work), but when I get home I'll see if I have time to play around. I don't anticipate any real problems getting things positioned properly. One word of advice though - *don't* try using 'position:absolute;' to get things situated. You won't need it in this case, and it tends to cause more problems than it solves when used for normal layout.
There are still a few of those 'old bad habits' hanging around in the code, and I'll go through those later as well. Perhaps we'll even move you up from HTML 4.0 to XHTML 1.0
{{edit - one thing that needs to be fixed, and which may be causing some of your problem:
code:
<div style="content">
Should be
code:
<div class="content">
There are also a couple minor validation errors which may be contributing as well.
quote:Please explain. This has been my understanding...
Well, I don't know a browser that doesn't ignore the DTD (excluding SGML browsers like Panorama), and I would be surprised if anyone doesn't. The only thing browsers do with the DOCTYPE declaration is to sniff it.
From: Somewhere over the rainbow Insane since: Mar 2001
posted 05-29-2004 01:37
The poster has demanded we remove all his contributions, less he takes legal action.
We have done so.
Now Tyberius Prime expects him to start complaining that we removed his 'free speech' since this message will replace all of his posts, past and future.
Don't follow his example - seek real life help first.
Of course, both that link and what you're saying alevice support what HZR is saying.
The browser looks at the doctype only to determine which of its own internal rules to follow, as opposed to actually referring to the doctype definition.
I would definately like more info on this though, as it has been too long since I've read up on the specifics...
Rob - I've played around a little bit, but need to refine some things before it's worth showing to you.
HZR pointed out a couple of important things, and there are more to add as well - back in a bit.
Thanks again. I should mention that there's no hurry on this. It will take time to get it right. I probably won't look seriously into it again until Tuesday. Enjoy your weekend!
BTW, keep in mind that the main page of the site is different than the others. Use faculty/faculty.cgi or microarray/index.cgi instead of the main page.
From: Somewhere over the rainbow Insane since: Mar 2001
posted 05-29-2004 10:55
The poster has demanded we remove all his contributions, less he takes legal action.
We have done so.
Now Tyberius Prime expects him to start complaining that we removed his 'free speech' since this message will replace all of his posts, past and future.
Don't follow his example - seek real life help first.
quote:HZR said document type definitions are ignored.
Yes, we were talking about DTDs referenced by the DOCTYPE declaration, not something that is hardwired into the browsers (and which I strongly doubt looks anything like a DTD)
quote:"quirks mode" or "standards mode" are just that, document type definitions stored locally
by the browser which will be used to parse the current document.
They are just two rendering modes and are allowing more sloppy code. Browsers are just tag slurpers, they are not using DTDs to parse documents.
From: Somewhere over the rainbow Insane since: Mar 2001
posted 05-29-2004 13:08
The poster has demanded we remove all his contributions, less he takes legal action.
We have done so.
Now Tyberius Prime expects him to start complaining that we removed his 'free speech' since this message will replace all of his posts, past and future.
Don't follow his example - seek real life help first.
Tyberius Prime
Paranoid (IV) Mad Scientist with Finglongers
From: Germany Insane since: Sep 2001
posted 05-29-2004 13:57
they need to - you can't intepret tags from a dtd - it only tells wether a document validates or not.
It doesn't contain anything about rendering or even determing the meaning of a tag, which needs to be 'hardwired' into the browser (meaning it's probably easy enough to change if you had the source).
From: Somewhere over the rainbow Insane since: Mar 2001
posted 05-29-2004 14:04
The poster has demanded we remove all his contributions, less he takes legal action.
We have done so.
Now Tyberius Prime expects him to start complaining that we removed his 'free speech' since this message will replace all of his posts, past and future.
Don't follow his example - seek real life help first.
to clarify a bit what InI and Tyberius Prime says, if need be, let's add that the browsers not necessarily use the "real and official" DTDs of the W3C. I especially think to IE which allow document structures forbiden by the official DTDs. Obviously, not using the "real and official" DTDs is a bad practice which cost more money and time to the browser vendors.
From: Somewhere over the rainbow Insane since: Mar 2001
posted 05-29-2004 14:29
The poster has demanded we remove all his contributions, less he takes legal action.
We have done so.
Now Tyberius Prime expects him to start complaining that we removed his 'free speech' since this message will replace all of his posts, past and future.
Don't follow his example - seek real life help first.
From: Somewhere over the rainbow Insane since: Mar 2001
posted 05-29-2004 15:11
The poster has demanded we remove all his contributions, less he takes legal action.
We have done so.
Now Tyberius Prime expects him to start complaining that we removed his 'free speech' since this message will replace all of his posts, past and future.
Don't follow his example - seek real life help first.
quote:Well, about question one, it explicitely SAYS mozilla does read dtds.
In that link? Where?
quote:While you can't prevent your browser from failing to comply with standards,
adding and using a correct doctype definition REALLY matters.
Are you talking about a DOCTYPE _declaration_? Mozilla won't read your DTDs. And if you want proof to that, try this simple HTML fragment
code:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd" [
<!ENTITY test "this won't work">
]>
<title>test</title>
<p>&test
From: Somewhere over the rainbow Insane since: Mar 2001
posted 05-29-2004 22:33
The poster has demanded we remove all his contributions, less he takes legal action.
We have done so.
Now Tyberius Prime expects him to start complaining that we removed his 'free speech' since this message will replace all of his posts, past and future.
Don't follow his example - seek real life help first.
/* Sidebar should stretch from top to bottom so that content is constrained to one neat column. There should be a corner logo with a nav bar beneath. */
Try setting the margin-left of your main content div to the width of your left navigation.
You should also set either padding-top or margin-top to clear it of the top bar.
Alternatively you could use absolutely positioned divs, (declaring the top and left values of each div on a page) But this may cause problems if you would like to have scalability.
I'm curious as to exactly what problems you are now seeing.
What I see is the following (Windows XP):
Home Page (IE 6, FF .8):
1. ccbc logo is somewhere in the middle and not placed to the right (which is what I assume you want)
2. content scrollbar hidden under header
Other pages (IE 6):
1. content scrollbar hidden under header
Other pages (FF .8):
1. content scrollbar appears over header
2. ccbc logo scrolls off page when scrollbar is used
I did not see any problems with the sidebar when resizing the page in either IE 6 or FF .8.
To fix the scroll bar problems, since header and sidebar are position:fixed, why not set the content div as position:fixed as well? I think this could have the scrollbar fully visible under the header (if this is what you want...).
To fix the disappearing ccbc logo, I notice that on the other pages (not home page), the ccbc logo is not in the header div but rather the content div...
To fix the misplaced ccbc logo on the homepage, I'd suggest float:right for the <img> tag or the enclosing <a> tag.
As far as placing the CSS inline to simplify R&D, I would disagree. I think that having the CSS in an external file is much simpler. Change the CSS file, refresh the page in the browser and BOOM: the changes are immediately visible.
The way you have it now, your CSS is scattered between files and you will require some effort to merge/consolidate the code...
Thanks for the feedback. I've been working extensively on the page today. Let me explain the current state of affairs:
I set out on this road to learn how to get rid of tables and use CSS exclusively. As of this posting, I've nearly concluded that there's no point.
The table hack I was using before (http://152.19.40.74/ccbc/microarray/vnb/index.cgi) works on all my test browsers in the same way: Mac using IE, Windows using IE6, and Linux using Mozilla. Everything looked the way I wanted it to, with no overlapping elements or hidden scroll bars or really any problems at all. There was a little extra padding in the nav bar on a Mac using IE, but otherwise it worked in all the browser/os combinations I have available to me.
I have tried to use CSS on the recommendations of people here. It has been quite frustrating. No matter what I do, it breaks in one browser or the other.
side note: Your last point about inline css being an issue does not apply to this site. All of the pages (except the main page, please ignore it for now) are built from the same header file, which is where the inline css is stored. In effect, I am doing what you suggest. A change one place automatically cascades through all the pages.
I first tried to simply place elements using embedded style elements, just to see how they should be structured to work properly. For example,
This approach gave me very straightforward code. No tables, a small handful of elements explicitly placed using CSS positioning. It was unsuccessful for many reasons, such as elements not situating properly in IE. I can't even remember all of the issues.
I then read a tutorial about recreating frames with css. The page was basically structured the way I wanted my page, so I adopted that approach. (http://www.fu2k.org/alex/css/frames/fixed) You'll noticed that the tutorial has its scrollbar hidden by the header, which is why mine is doing so now. Your fix might work if I try it.
The problems with this approach have been myriad. First, the corner logo. In Linux/Mozilla, I had everything looking perfect. But in IE, the logo was almost completely off of the page. In addition, the top 100 pixels worth of content was buried under the header. It is as though IE is completely ignoring directives such as top: 101px. The solution was to put a bunch of <br /> tags to move the content down and two corner logos. One is for IE, the other is for Linux. In Linux, the corner logo was scrolling away when I set it to absolute. Which it should. But the same absolute element was hiding offscreen in IE. On the flip side, if I set a corner logo to fixed and gave it a right margin of ~200px, it would show up where I wanted it to in IE but not in the right place in Linux. So I have both. Now, the only weirdness is that one of the copies scrolls in Linux, leaving a stable one behind. I can live with that for now.
In addition, IE was ignoring my css. I would embed a style using style="", and it would work. Moving the exact same style elements to the inline style sheet broke it.
Finally, I opened it up in Mac using IE, and the background: url() property does not appear to be working. It is a huge mess.
So I go back to my table hack, and everything is playing nicely, resizing effortlessly, looking right.
This forum is wonderful; the people here give informed and worthwhile advice. The general consensus seems to be:
1) use CSS instead of tables / 1 pixel tricks / other techniques that marry content to presentation.
2) It is incumbent on web professionals to learn and keep up with current standards.
3) Always use a DOCTYPE declaration to tell the browser how to interpret the page.
In theory, I agree with all three.
Here's the practice: I've been building web pages as part of my job for six years. I'm not a web professional by any stretch, but I'm not a newbie either. However, I have spent about 8 business days wrestling with a pure CSS page, and everything I read and do contradicts something else. "This browser doesn't support css tag A" or "This tage will do so-and-so in Windows but not in Mozilla". Trying to do the simplest things causes unexpected difficulties elsewhere. In that eight days, I could have built two entire web apps, and I am still no closer to having a pure CSS page. In fact, with all of the <if IE> workarounds and extensive style sheet modifications, the code is now bulkier than it was before.
Here's the simple fact the way I see it:
I have a page with no DOCTYPE declaration, a mishmash of CSS/table hacks/ other "bad" tricks, <FONT> tags, <BR> tags, etc. It works the way I want it to in the three os/browser combos that I have available.
It is no one's responsibility to help me build my pages. I have given CSS an honest try, with over a solid week of reading tutorials, WC3 recommendations, etc. and I am no closer to a functional page. Without some sort of assistance or clear direction, I simply cannot justify the continued lost work hours. I hope to "get it" soon with this forum's help or some other source, but I also have to worry about delivering the web apps that people need to do their jobs, which are working just fine without DOCTYPES or CSS.
I tried dummying up a simple layout using position:fixed which works in FireFox 0.8 but not IE6. A quick google on IE + position:fixed, tells me that IE has some problems with position:fixed. There are a number of workarounds that various people have developed, so I'm sure that you could make it work if you wanted to.
But before you go to all that pain, I have to ask: Are you committed to having the header and sidebar fixed in the viewport (browser)? If not, you can very easily attain the same layout by using the float property on your DIVs and I can assure you that you won't have the same cross-browser problems. In this case, of course, the whole page will scroll (not just the content DIV) which means that the header and sidebar may scroll off the page (depending on amount of content and the dimensions of the user's browser window). If you (or your client) can live with that, then that's what I would recommend.
I am not committed to having the header/sidebar stay fixed. I am committed to having everything line up, with no gaps, disappearing background images, or cross browser funkiness. Simple example: something like "background: url(images/background.gif)" works in IE and mozilla, but not IE on Mac.
From: Somewhere over the rainbow Insane since: Mar 2001
posted 06-05-2004 21:51
The poster has demanded we remove all his contributions, less he takes legal action.
We have done so.
Now Tyberius Prime expects him to start complaining that we removed his 'free speech' since this message will replace all of his posts, past and future.
Don't follow his example - seek real life help first.
posted 05-27-2004 22:45
Don't worry, I know I don't need tables. However, until I learn how to not use them, it stays. But thanks for pointing it out.
