"Robert Aldwinckle" <> wrote in message
news:#...
>
> "cranheim" <> wrote in message
> news:...
>
>
>>>>> The failing URL is
>>>>> http://www.wunderground.com/cgi-bin/...st?query=06033.
>
>
>> I tried the URL you suggested and got the same error as the URL I had
>> been using.
>> Thanks for your interest. Hopefully the web site will have a fix for this
>> problem as indicated in their response to me.
>> Charles Ranheim
>
>
> I'm not sure it was ever broken for me. I just corrected your apparent
> typo
> in the first URL and this works too:
>
> http://www.wunderground.com/cgi-bin/...st?query=06033
>
This could be dependent upon the individual browser used to connect - I've
had issues with a similar error on some sites before, and narrowed it down
to adverts or RSS feeds that were being "personalised" for me, and including
some javascript code that was attempting to insert HTML into a container
element that had not been closed. I'd often find that using my work PC I'd
get errors and my home PC I wouldn't, or vice versa.
Under IE6, and often in IE7, this sort of coding issue would result in the
browser closing down with an "Operation aborted" dialog, but in IE8 you now
get a warning message instead. More details about this issue are on the MS
site here:
http://support.microsoft.com/kb/927917
Other browsers seem to work around this issue by either deferring the code
execution until the container element has been closed in the parser, or by
ignoring the code execution. While the former would appear to be the option
that would most likely render the page as the author intended, MS took the
stance that having the browser throw an exception is better because it
should push the page author (either directly if the author sees the error,
or indirectly by getting visitors to the site to post the issue the author)
to fix the code, rather than the browser have to either defer or ignore the
execution of that code.
--
Dan
Similar Threads
Linear Mode
