malformed html
Hello,
Haven't been here in a while, place changed location on me. Why did it move to .net anyways?
Well let me get to my problem. Got some tables being output by perl and I am getting some very weird responses from them.
http://www.ifae.com/admin/comptixgui.cgi
1st. Why are three of the images aligning to the top of the table when they are clearly marked to align at the bottom.
2nd. Why do I have extra space below my drop down menu?
3rd. On Mac OS 9.2 IE 5, their is no bottom black line on the tables? That is not important, but it's buggin the snot outta me.
I think that is all I'm really worried about right now. Thanks in advance for any help I might recieve.
Ken Elliott
____________________________________________
If we are not supposed to eat animals, why are they made of meat?
Pimpin like a pimp with an electrofied pimpin machine!
taff posted this at 20:43 — 20th June 2002.
They have: 956 posts
Joined: Jun 2001
a wild guess:
could the fact that none of your attributes are contained in quotes be part of the problem?
Suzanne posted this at 01:21 — 21st June 2002.
She has: 5,507 posts
Joined: Feb 2000
You really need to validate the output, then go back and fix the perl code that's generating it. The stylesheet's outside of the head tag, almost none of your attribute values are enclosed in double quotes (as Taff noted), your table tags have errors in there somewhere (could be not closed, could be a different error), and you have the wrong values for some attributes.
In Perl, to put double quotes around attribute values in HTML generated by it, you just need to escape out the double quote.
So: valign=\"middle\"
Also, it's entirely pointless to use a class in a font tag when there is nothing else in the font tag. And even when there is. If you're using CSS, let go of the font tag! Just ditch it!
Answer to the Most Pressing Problem #1
Because you are using % for height.
Answer to the Most Pressing Problem #2
Because of the way it's built. There is an extra closing font tag (see above rant about the use of font tags in the first place). But if you want to kill the space, put the form elements (select and input tags) into a table. Form elements should be placed in a block level element anyway.
Answer to the Most Pressing Problem #3
You are missing a set of closing tags -- and it won't render without them.
Ken Elliott posted this at 14:35 — 21st June 2002.
They have: 358 posts
Joined: Jun 1999
Pimpin like a pimp with an electrofied pimpin machine!
Suzanne posted this at 19:34 — 21st June 2002.
She has: 5,507 posts
Joined: Feb 2000
The font tag is deprecated. For inline changes, use instead of .
Why do you have to use % for those ones, but not for the rest? I don't know why it's doing that, only that the % is causing the problem. Better to work out the percentage into pixels.
input, select, option, textarea, et cetera should be enclosed in a block level element (table, p, div). so...
(where ble = whatever element you're using)
"Weird" isn't helpful, lol. What are the rendering errors, what OS, what browser?
ROB posted this at 01:46 — 22nd June 2002.
They have: 447 posts
Joined: Oct 1999
technically i believe, and its possible im wrong here, attributes without quotes are valid as long as the attribute doesnt include spaces.
Also, one thing to note is mixing percentages and absolute pixel values in table heights and widths is a no-no. youre table and all components of it should use either percentages OR absolute values, not a combiniation (even though they may look ok in IE)
Suzanne posted this at 06:03 — 22nd June 2002.
She has: 5,507 posts
Joined: Feb 2000
actually, no. all attribute values must be enclosed in double quotes for forward compliance.
ROB posted this at 16:33 — 24th June 2002.
They have: 447 posts
Joined: Oct 1999
from the w3.org validator
nya
Want to join the discussion? Create an account or log in if you already have one. Joining is fast, free and painless! We’ll even whisk you back here when you’ve finished.