Worst IE7 trap ever?

[michael180]

REF: http://moderntimes.com/tmp/

The page above validates, but it only works in FF, and Safari, a bit better in Opera, but a disaster in IE7!

Quirks mode doesn't apply.

I can't even get the logo.gif to display in IE7, never mind the various divs.

Any suggestions?

Thanks,
Michael

[CFMaBiSmAd]

Irregardless of "passing" a validator test, there is no closing </form> tag present.

[michael180]

I know, when I add the closing </form> tag the page won't validate. moreover the closing tag does nothing, I'll tackle the closing tag if and when I can get this crummy IE to work.

But thanks,
Michael

[CFMaBiSmAd]

Without a closing </form> tag everything after the opening <form tag is considered a form element and won't be rendered by the browser unless it belongs in a form. In fact, the form probably won't be rendered until the closing tag is seen.

The validator you are using seems suspect.

[michael180]

I just noticed it's a "self-closing" tag.

[BWiz]

Line 19:
<form action="http://search.freefind.com/find.html" method="get" accept-charset="utf-8"/>Line 27:
<input class="find" src="image/blk_search_btn.png" type="image" id="submit" value=""/></form>Notice anything?

EDIT: Never mind, you found the answer anyway.

[michael180]

I am totally confused. I've never seen IE7 this fouled up. Even IE5 for the Mac, renders the page acceptable.

[michael180]

I use the W3C Markup Validation Service. As I said the </form> tag or not, it makes no difference in the way the page is displayed in IE7. It's perfect in FF, and Safari.

[CFMaBiSmAd]

The <form ... tag cannot be self-closed - no />. It requires an explicit closing </form> tag as it is a block level element that encloses other form elements.

The following will fix your validation issue (it validates correctly at w3.org) -
<form action="http://search.freefind.com/find.html" method="get" accept-charset="utf-8">
<div id="search">
<input type="hidden" name="id" value="57852721"/>
<input type="hidden" name="pageid" value="r"/>
<input type="hidden" name="mode" value="all"/>
<input type="hidden" name="n" value="0"/>
<input type="hidden" name="_charset_" value=""/>
<input type="hidden" name="bcd" value="÷"/>
<input type="text" name="query" size="17"/>
<input class="find" src="image/blk_search_btn.png" type="image" id="submit" value=""/>
</div>
</form>

Edit: The following attached image is what your web page looks like in IE7 with the above code change -

[Arbitrator]

I use the W3C Markup Validation Service. As I said the </form> tag or not, it makes no difference in the way the page is displayed in IE7. It's perfect in FF, and Safari.Technically speaking, <form …/> and <form …></form> are the same thing in an XHTML (XML) document, hence the error about closing the element twice.

When you serve XHTML as HTML (fake or pseudo‐XHTML), the document gets treated as HTML; there’s no such thing as self‐closing tags in HTML. This means that the form element is, technically, open. Internet Explorer is overreacting a bit, but the issue is an authoring error rather than a browser error.

To complicate matters, the slash in a closing tag means something totally different in an HTML document, which may throw HTML (SGML) validators off. Below is an example of NET (null end tag) syntax, which is not supported by any major browser, but is otherwise correct HTML.

<form action="action.php"/
<input type="text"/
/

The above is equivalent to the below.

<form action="action.php">
<input type="text">
</form>

In short, you cannot use any of XHTML’s special features when sending it as HTML; pseudo‐XHTML is essentially just HTML with a strict syntax. The solution is to avoid using self‐closing tags in XHTML served as HTML except for elements that are empty (elements that are forbidden an end tag) or, better yet, to use HTML instead and save yourself some confusion.

---

If you decide to go with the pseudo‐XHTML, know that, in real XHTML documents, the primary CSS background should be assigned to the root element (html) and that <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1" /> is an ineffective method of setting the character encoding (use an HTTP header).

You could also fix some errors. type="png" should exhibit the correct media type for the PNG format (image/png). Your page also misuses the acronym element to mark up non‐acronym content. If those are references, the cite element might be appropriate; otherwise, the acronym elements should be replaced with span elements or removed entirely (the attributes could be moved to the a element).

[croatiankid]

When you use the text/html, the document is literally parsed as HTML. The only reason <br /> doesn't print a line break and ">" (which it should) is because of a parsing bug present in almost every rendering engine (shorttags).

Also, you should know that certain browsers don't follow the accept-charset attribute of the form tag (IE when I last checked sends data using the same charset as the document is sent with) and that, unfortunately, there is no reliable way of determining the charset incoming text is using.

[michael180]

REF: http://moderntimes.com/tmp/



If you decide to go with the pseudo‐XHTML, know that, in real XHTML documents, the primary CSS background should be assigned to the root element (html) and that <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1" /> is an ineffective method of setting the character encoding (use an HTTP header).



Thanks all.

I'm completely confused about this, I always thought the preferred method was to use DOCTYPE strict, and Strict meant XHTML? I don' t understand this pseudo vs. real XHTML?

I thought by sending it as "DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict", I was sending it as XHTML?

I used acromym because I wanted to show mouseove information.

Anyway, again thanks,

Michael Mills