Forum Moderators: open

Message Too Old, No Replies

Interesting Quandry...

why did deleting charset meta tag seem to fix page?

         

oninoken

3:55 am on May 3, 2005 (gmt 0)

10+ Year Member



Today I was perplexed by IE. It seemingly refused to display an image at 100% height. I use the images as containers for dynamic content, so I need them to resize with the amount of content. I've used the technique a few times for module tables in php nuke, so I know it works.

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

oninoken

4:42 am on May 3, 2005 (gmt 0)

10+ Year Member



Okay,

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.

tedster

4:45 am on May 3, 2005 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



My first thought is that you may have deleted the top line of the file - which was actually the doctype declaration rather than the charset meta tag. If you had Dreamweaver set to being the document with a full DTD, that would make the page display in standards mode - which is a bit different from quirks mode, especially in its treatment of images. Modern browsers switch over to quirks mode when there is a missing or incomplete DTD.

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.

oninoken

5:22 am on May 3, 2005 (gmt 0)

10+ Year Member



Currently, the site is displaying as expected with the first four lines of code as follows:


<!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.

kaled

8:19 am on May 3, 2005 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



The absence of an url in the doctype will, in this case, cause IE to render the page in quirks mode.

Kaled.

tedster

11:47 am on May 3, 2005 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



You may find this post helps get you started:

[webmasterworld.com...]

oninoken

1:27 pm on May 3, 2005 (gmt 0)

10+ Year Member



Thank you gentlemen.

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

MatthewHSE

3:40 pm on May 3, 2005 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



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.

tedster

5:56 pm on May 3, 2005 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



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.