Announcement

**David** · Mar-06-2008, 10:32 PM

If all the results are appearing in the source code then maybe you have done something silly, like used white text on a white background?

Can you post the search URL that shows the problem.

**orionblu** · Mar-06-2008, 11:47 PM

hehe, I'd make a snarky comment about not being that stupid, if I weren't sure that I'm not doing something equally stupid.

Thanks for the help - please check www.bluwebsolutions.ca/petes/faqs.php to see the dev url (post example is http://www.bluwebsolutions.ca/petes/askpete.php?zoom_query=apples&zoom_per_page=10&zoo m_and=0 ) .

**Ray** · Mar-07-2008, 12:23 AM

You've failed to close your HTML comments properly, so you ended up commenting out the entire page.

Near the top of your page, you have this script code:

Code:

<script type="text/JavaScript">
[B]<!--[/B]

And then there was an attempt at closing it before the </script> tag, but it turned out looking a bit wrong:

Code:

[B]//]]>[/B]
</script>

That's not a valid end comments marker which is likely what you meant there. It should look more like this:

Code:

//-->
</script>

Some examples here on the w3 site for reference.

As is one of the funny things with browsers behaving unexpectedly when given dodgy HTML, that page actually renders in Firefox. And also funnily enough, your other pages with the same mistake is rendering in IE which is likely why you didn't see the problem before. But a quick feed of the page into the W3 Validator would throw up some warning signs.

By the way, I noticed another bit of invalid HTML a few lines below, which is unrelated to the problem, but needs fixing nonetheless:

Code:

<body  "MM_preloadImages('images/bspecialtygrocery1.jpg', [I]... etc.[/I]

You probably meant:

Code:

<body [B]onLoad=[/B]"MM_preloadImages('images/bspecialtygrocery1.jpg', [I]... etc.[/I]

Hope that helps.

**orionblu** · Mar-07-2008, 12:00 PM

Thanks Raymond for the tip - it worked, but I have to point out that the end tag in question is that which Dreamweaver 8 generates, and I've never noticed any problems with it. That specific comment tag doesn't actually generate an error for xtransitional (I went back and looked at other sites that are, this one is not out of dev yet so not compliance is not complete but mainly alt tags and the like), so I'm still stumped as to why it broke on this script.

Regardless, it is working and I appreciate your time. Thanks again!

**Ray** · Mar-10-2008, 12:02 AM

Originally posted by orionblu View Post

Thanks Raymond for the tip - it worked, but I have to point out that the end tag in question is that which Dreamweaver 8 generates, and I've never noticed any problems with it.

I've got Dreamweaver 8 here, and I've just tried to generated a menu item with MM_swapImgRestore() and other similar functions, and the end comment tag is correctly specified as "//-->" and not "//]]>".

Perhaps there's a bug in Dreamweaver for a certain setting that you have enabled - but I have not seen this problem on other Dreamweaver sites. Or perhaps the scripts/objects of your Dreamweaver install has been modified?

Originally posted by orionblu View Post

That specific comment tag doesn't actually generate an error for xtransitional (I went back and looked at other sites that are, this one is not out of dev yet so not compliance is not complete but mainly alt tags and the like), so I'm still stumped as to why it broke on this script.

I presume you mean XHTML Transitional. That was what I validated your page against originally so I'm pretty sure "//]]>" doesn't validate.

However, the tricky thing with an invalid close comments tag is that you potentially don't break the HTML if another (correctly closed) comment occur after it in a suitable position.

For example,

<head>
<title>My title here</title>

</head>
<body>
my page ... etc.
</body>

In the above example, the invalid close comment tag has little effect in breaking the HTML because another comment tag following it closed it. All that happened was some unintended part of the page (the meta description) got commented out as well. So the above would validate despite the dodgy tag.

The page broke because Zoom's output had a HTML comment much further down below the page. This meant that it ended up commenting out a crucial portion of the page such as the open <body> and <table> tags. For example, if you can imagine the above example but having moved the second line of comments down past the body tag, it would look something like this:

<head>
<title>My title here</title>

</body>

This example now would not validate, and would likely render broken. But the problem is still the dodgy "//]]>" tag.

It is quite likely that some of your other pages were rendered by IE and Firefox due to some error handling for cases like this, where they realize if an open comment tag was never closed at all, it would ignore the comments block all together (which allowed the page to render). But since Zoom's output contained a close comment tag (for its own validly opened and closed comment), it ended up creating a proper comment block that the browser would recognize.

Announcement

browser hides custom results, appear in source

browser hides custom results, appear in source

Comment

Comment

Comment

Comment

Comment