IE displaying syntax instead of parsed page layout

[RobM]

Hi folks

Has anyone seen this before... have xhtml page (generated by a JSP) which,
when viewed _via web server_ it causes IE to display the syntax (its own
version too, altered xml) instead of the page. Yet... when view source and
save it to a file.html on local disk and open it again within IE from that
disk file, it displays the page ok. (!?!??). Something to do with http
headers coming down the line?

Other browsers dont have this issue.

The JSP which generated this page also generates it as readonly (no input
fields) depending on business rules... this DOES display OK on IE.. and this
uses the same headers and style sheets etc but without all that massive
javascript. So must be something in the code makes a difference?

WHy does IE display the syntax and not the page itself? It validates with
w3c checker thing.

The page is a bit big and complicated, I'm doing some maintenance on it (it
was many frames), its xhtml because of an example I found which enables a
div scrolling but the use of 'fixed' causes problems in IE and this is the
evidently the way to go (searched for examples on removing frames and css).

The source is on http://users.bigpond.net.au/snootfrog/wip/viewsource.html

As mentioned, its big and horrific, but saved to a file and opened from that
file it then displays somewhat!

Pointers to the reason appreciated !
Cheers
Rob

 

[Neredbojias]

With neither quill nor qualm, RobM quothed:

Hi folks

Has anyone seen this before... have xhtml page (generated by a JSP) which,
when viewed _via web server_ it causes IE to display the syntax (its own
version too, altered xml) instead of the page. Yet... when view source and
save it to a file.html on local disk and open it again within IE from that
disk file, it displays the page ok. (!?!??). Something to do with http
headers coming down the line?

Other browsers dont have this issue.

The JSP which generated this page also generates it as readonly (no input
fields) depending on business rules... this DOES display OK on IE.. and this
uses the same headers and style sheets etc but without all that massive
javascript. So must be something in the code makes a difference?

WHy does IE display the syntax and not the page itself? It validates with
w3c checker thing.

The page is a bit big and complicated, I'm doing some maintenance on it (it
was many frames), its xhtml because of an example I found which enables a
div scrolling but the use of 'fixed' causes problems in IE and this is the
evidently the way to go (searched for examples on removing frames and css).

The source is on http://users.bigpond.net.au/snootfrog/wip/viewsource.html

As mentioned, its big and horrific, but saved to a file and opened from that
file it then displays somewhat!

Pointers to the reason appreciated !
Cheers
Rob

Wow, that's really interesting. I get a color-coded view of the source,
like in an html-enhanced editor. Didn't know IE could do that. Could
it be perhaps because the page name is "viewsource"? Dunno...

 

[Toby Inkster]

Something to do with http headers coming down the line?

Perhaps, but IE occasionally ignores HTTP headers anyway. I think this is
your problem.

Ditch everything before the DOCTYPE, including the XML prologue, all that
white space and the BOM.

 

[RobM]

With neither quill nor qualm, RobM quothed:

Wow, that's really interesting. I get a color-coded view of the source,
like in an html-enhanced editor. Didn't know IE could do that. Could
it be perhaps because the page name is "viewsource"? Dunno...

*grin* .. if only...

No, this was a job to combine 5 frames which is done mostly, but I'm going
to give the frame simulation (i.e. centre bit scrolling) a miss, too much
hassle. I think I'll convince them on a std html 4 page which scrolls
together, the major streamlining job (ex frames) done.

Thanks for looking
Rob

 

[RobM]

Perhaps, but IE occasionally ignores HTTP headers anyway. I think this is
your problem.

Ditch everything before the DOCTYPE, including the XML prologue, all that
white space and the BOM.

Thanks Toby, no go though. White space was from JSP generator, embedded code
replacements. I could fix that though, but hasnt changed it. I have the
readonly version (no <form>) which does work and slowly copying over
sections from this form-based one, I'll hit it soon. However, the dropdown
(<select>) lists stay onscreen when the page scrolls 'under' the top area,
so this wont be the way to implement.

No, this was a job to combine 5 frames which is done mostly, but I'm going
to give the frame simulation (i.e. centre bit scrolling) a miss, too much
hassle. I think I'll convince them on a std html 4 page which scrolls
together, the major streamlining job (ex frames) done (used to be 5 JSP
pages with separate server processing for each .. header.. links... bottom..
detail... and framepage). Simple frames scrolling simulation with CSS looks
good until you try it on IE hence the attempt based on here:
http://www.webreference.com/programming/css_frames/ but doesnt look good
with <form> based pages.

Thanky for looking!
Cheers
Rob

Thanks for looking
Rob

 

[RobM]

Thanks Toby, no go though. White space was from JSP generator, embedded code
replacements. I could fix that though, but hasnt changed it.
Thanks for looking
Rob

That's interesting. Spoke too soon. Had a look at the hex of the file and
noticed BOM etc, used my text editor (ultraedit) to convert utf-8 to ascii
and now it does display! Thing is... have to have a think how to handle that
originally coming from the output of a JSP page from a web server. On the
right track, ta Toby.

Anyfrog, the dropdowns still scroll visually above the top bit, so I'll stop
the jiggery-pokery frames scrolling simulation and go back to html 4, at
leat until IE's fixed or someone can offer a better way?

Cheers
Rob

If anyone's interested: http://www.webreference.com/programming/css_frames/

 

[dorayme]

Perhaps, but IE occasionally ignores HTTP headers anyway. I think this is
your problem.

Ditch everything before the DOCTYPE, including the XML prologue, all that
white space and the BOM.

I have noticed similar behaviour in Safari from time to time when
I drag an .html file over the open window, the source is
displayed rather than than the web page. It happens sometimes
when trying to access a server based .html file too (in the
ordinary way of a url...). And always been puzzled by this. I
think it happens in other browsers too but I can't recall now...
I cannot recall anything in these files before the doctype but I
will look closely next time. Anyway, this behaviour is not
confined to just IE. I think that on some occasions reloading (by
browser button) sometimes causes the webpage to appear (off/on
line?)

 

[RobM]

I have noticed similar behaviour in Safari from time to time when
I drag an .html file over the open window, the source is
displayed rather than than the web page. It happens sometimes
when trying to access a server based .html file too (in the
ordinary way of a url...). And always been puzzled by this. I
think it happens in other browsers too but I can't recall now...
I cannot recall anything in these files before the doctype but I
will look closely next time. Anyway, this behaviour is not
confined to just IE. I think that on some occasions reloading (by
browser button) sometimes causes the webpage to appear (off/on
line?)

Cheers dorayme. I think its something to do with encoding. Toby had it.. I
checked the demo file I had here and found it was unicode/utf-8 (not up on
that too much yet), every byte had 00 between. I used text editor to
"convert to ascii" and updated the file on my server and it now displays. I
think IE didnt like that encoding. I may try adding below to my JSP, as in
prod its coming from a web server dynamically generated, so must be
something to do with the encoding I'm using. I'm going to go back to common
html 4 syntax without the simulated frames scrolling stuff, its going to
cause too much grief from different browser I can see it coming. They'll get
used to scrolling the page, esp if I rearrange some data.
<%@ page contentType="text/html; charset=UTF-8" %>

Cheers

Rob

 

[Toby Inkster]

I have noticed similar behaviour in Safari from time to time when
I drag an .html file over the open window, the source is
displayed rather than than the web page.

I occasionally see the same thing in Opera too, and I'm pretty sure I've
seen it in Mozilla (Seamonkey).

 

[dorayme]

I have noticed similar behaviour in Safari from time to time when
I drag an .html file over the open window, the source is
displayed rather than than the web page. It happens sometimes
when trying to access a server based .html file too (in the
ordinary way of a url...). And always been puzzled by this. I
think it happens in other browsers too but I can't recall now...
I cannot recall anything in these files before the doctype but I
will look closely next time. Anyway, this behaviour is not
confined to just IE. I think that on some occasions reloading (by
browser button) sometimes causes the webpage to appear (off/on
line?)

Cheers dorayme. I think its something to do with encoding. Toby had it.. I
checked the demo file I had here and found it was unicode/utf-8 (not up on
that too much yet), every byte had 00 between. I used text editor to
"convert to ascii" and updated the file on my server and it now displays.[/QUOTE]

Well, I am at sea on this? By and large I do not have problems
mentioned above. For the odd case, reloading a url often "fixes"
it.

Is there a best general, safe practice to set one's text editor
preferences for html and css files to avoid this sort of thing?

I know how not to have anything before the doctype, and I am very
good at not having whitespace. I can get rid of it really easily
using the delete key. I am fast and efficient and really
competent on this.

But I don't know anything about BOM, when it is at home or just
passing me in the street. And I don't know whether or not
pressing my Convert to ASCII command is doing anything, I just
assume I am in ASCII. Honestly, I really do wonder how I get by!

Better read the BBEdit manual again after all these years... (but
maybe I will be none the wiser as to what practically to set my
prefs?)