Forum Moderators: open
However, in this case, it was not working. The code was not complex. I attempted every combination of image attributes I could think of, using both html attributes, and css attributes, in both the table definition and the image tag.
Ultimately, the problem appeared to be solved by removing the charset meta tag from the page. Now, wiser minds have told me this makes no sense. But it definately cleared up the problem.
So that leaves me with the question of why did that appear to work?
here are some facts:
1. the page was developed and published using dreamweaver mx2004. I don't know if that'll spark any ideas for anyone.
2. removing the charset metatag appeared to solve the problem.
3. other pages on which the code works, have the charset metatag, but were developed using a text editor, and not dw.
4. It has always worked as expected in Mozilla.
Thanks for your time,
Oninoken
I seem to have chased the problem down to the doctype loose.dtd
Using a copy of my previously unworking page as a sample, I tried removing various elements to see what was causing the problem. Now, I was able to get the page to display as I wanted by removing the loose.dtd doc type.
I believe that dtd is an xml definition. Now, since removing the charset also got the result I was looking for, I infer, (i.e. wildly speculate) that there was some sort of interaction between the loose.dtd and the charset that led to the display attributes for height on an image tag to not render correctly in IE.
If any of you know better, please correct me. But this seems to be the most likeley case to me.
Now, I've yet to discern what, if anything, I loose by not having the loose or strict dtd in my page, but it seems to display fine in my two main target browsers: IE and Mozilla.
If anyone has anything else to add, please do. I'm not convinced I've gotten this right.
Can you verify which tags it is that you deleted? Paste the charset meta tag in and see if the problem returns. If it does, we definitely have a strange thing going on here.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" >
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
To test I first deleted the meta tag with the charset in it. That got the site to display as expected. I got more than one response from colleagues that said that didn't make sense. So I stuck the meta tag back in, and deleted the DOCTYPE line. This also got the page to display correctly.
At that point, I noticed that there were two elements to the doctype line, and then deleted the loose.dtd portion of it, and ended up with a file that displayed as I expected it to, and still had the charset in place.
This is the first site I've ever developed in dreamweaver, so I'll admit there are still many secrets to it that I am not privy to. this doccument set up option would be one of them.
[webmasterworld.com...]
In trying to figure out what was going on last night, I actually ended up chasing down quirks and standard mode on the web. Here's one of the better pages I found.
[quirksmode.org...]
I think a problem alot of developers have is that over the past, we evolved a "just make it work" attitude towards creating web pages. I know I sure did. Thing is, I do tons of testing on multiple os, multiple browser. Usually, I can get cross compatibility on everything I'm doing.
Of course, I'm finding out now, this is because I'm doing all sorts of stuff in quirks mode, to address the whims of each browser.
I need to look into box model more, I've been wanting to get away from tables for some time now. Just haven't had the time, really.
thanks for your help!
Oni
Today I was perplexed by IE.
Just a day in the life of a webmaster! ;)
Seriously, though, since the page worked in Mozilla, the most likely problem is that IE in Standards mode needs some sort of hack or workaround for one portion or another of your markup. Oddly, I've found that many of my IE woes go away by adding an extra container div around the problem areas. It's ugly, and I should probably try to work out a better solution, but it works.
we evolved a "just make it work" attitude
I do tons of testing on multiple os, multiple browser.
Those two go together - and make a grand argument for the standards movement. The more I get the standards mode, valid mark-up approach down, the less my cross-browser checks turn up trouble. This brave new standards world saves time - there's nothing like seeing the page render as inteded, browser after browser, when I start my compatibility tedsting.