Firefox & Excel's "Save as web page.."

C

cwhaley

Ever since I discovered that Excel had a "Save as Web Page..."
feature, I've used it for a variety of things. It's so convenient to
have the code generated automatically, then just FTP it to my site(s).

Where I've run into problems is uploading a whole workbook this way
and having Firefox display the results.

Here's an example... http://TSX.ProfiTrend.com

If you click on DATA & CHARTS in either IE for Windows or Safari for
Mac, you'll see my workbook of charts and tables as they should be. If
you use Firefox, you'll see a code dump.

I've tried to resolve this with both Microsoft and Firefox, but you
can imagine the replies I've received. Microsoft blames Firefox for
the problem, while Firefox says that Microsoft isn't using industry
standard code, so Firefox will have problems because they "do" follow
industry standards.

I'm asking anyone (who has applied this method of generating web
content), if they've experienced the same thing; and, if so, whether
they've resolved it. I'd rather not have to tweak the code that Excel
generates, but if there is something I could be doing to my Excel
workbook before "Save to web page.." that might help, I'd love to
know.

There have been a few times when the problem went away, but it somehow
comes back without my knowing what I did differently.
 
J

JE McGimpsey

cwhaley said:
I'm asking anyone (who has applied this method of generating web
content), if they've experienced the same thing; and, if so, whether
they've resolved it. I'd rather not have to tweak the code that Excel
generates, but if there is something I could be doing to my Excel
workbook before "Save to web page.." that might help, I'd love to
know.
Click to expand...

Is XL generating all the Javascript code?

I didn't look exhaustively, but neither browser is exactly correct, in
my opinion, though Safari comes closer to handling things the way I
would like.

The problem appears to be that the head element is malformed, with a
couple of extra

//-->
</script>

tags. Since they end the script element and there are no additional
non-displaying elements open (other than <head>), Firefox displays what
comes next, even though the </head> tag hasn't been reached (the spec
for HTML 4.01 reads "User agents do not generally render elements that
appear in the HEAD as content."). I greatly prefer Safari's ignoring the
text until the <body> tag is reached.

Especially for HTML4.01, it's hard to say that either one is wrong, but
there's nothing within XL that I know of that can be tweaked to avoid
the problem.
 
C

cwhaley

Is XL generating all the Javascript code?

I didn't look exhaustively, but neither browser is exactly correct, in
my opinion, though Safari comes closer to handling things the way I
would like.

The problem appears to be that the head element is malformed, with a
couple of extra

//-->
</script>

tags. Since they end the script element and there are no additional
non-displaying elements open (other than <head>), Firefox displays what
comes next, even though the </head> tag hasn't been reached (the spec
for HTML 4.01 reads "User agents do not generally render elements that
appear in the HEAD as content."). I greatly prefer Safari's ignoring the
text until the <body> tag is reached.

Especially for HTML4.01, it's hard to say that either one is wrong, but
there's nothing within XL that I know of that can be tweaked to avoid
the problem.
Click to expand...

I don't know how much to thank you, since I've been living with this
annoyance for so long, and no one has identified the problem.

I guess you've figured out that I do my web design work via WYSIWYG
software, so I rarely have to even look at HTML or JavaScript -- much
less have to debug it.

But to answer your question, yes, Excel generates all the code
including the faulty bits you've identified. I removed them, and
Firefox displays the charts and tables correctly. The formatting isn't
ideal, but the convenience of generating web material this way more
than makes up for that as far as I'm concerned.Thanks JE

It'll still be a pain to go in and remove those faulty bits of code
with every weekly update, but it sure beats any other solution I'm
capable of implementing.

So, thanks again. Somehow I'll try to get your identification of this
problem to both Firefox and Microsoft. If you have connections with
either one, maybe you can get the message to them faster than I can.

Wow... a solution at last!!!!!!!!

Thanks JE
 
P

Phillip Jones

JE said:
Is XL generating all the Javascript code?

I didn't look exhaustively, but neither browser is exactly correct, in
my opinion, though Safari comes closer to handling things the way I
would like.

The problem appears to be that the head element is malformed, with a
couple of extra

//-->
</script>

tags. Since they end the script element and there are no additional
non-displaying elements open (other than <head>), Firefox displays what
comes next, even though the </head> tag hasn't been reached (the spec
for HTML 4.01 reads "User agents do not generally render elements that
appear in the HEAD as content."). I greatly prefer Safari's ignoring the
text until the <body> tag is reached.

Especially for HTML4.01, it's hard to say that either one is wrong, but
there's nothing within XL that I know of that can be tweaked to avoid
the problem.
Click to expand...

The reason why FF or SeaMonkey doing as they do is they follow World
Wide Web Consortium (even MicroSoft is a member though the don't follow
the) standards. So if Safari is ignoring the code its not following
Standards.

The object of universal Standards is that everyone if they would code to
standards then all websites would show up exactly the same on all known
current web browsers. So that would mean that the sites should either
look the same or much the same, taking into account consideration for
the size of Monitors, OS used and Fonts sets loaded.

That the reason why many don't like IE's habit of "self-healing" that is
taking sloppy written code and anticipating what tags were left out. 99%
of the time it works out 1% of the time there are weird consequences.
But what this self-healing does is allow a designer to write the code
look at it on IE and say oh Perfect. Upload it then when other browsers
try to look at they can make any sense out of it. Then he has to go back
and figure out what he left out, if he is inclined to do. If he's not he
just lets everyone know it can only be viewed on IE.


(NOTE: the reference to "He, or he" is a hypothetical person. Doesnt
reflect upon any certain individuals known or unknown.)
--
------------------------------------------------------------------------
Phillip M. Jones, CET |LIFE MEMBER: VPEA ETA-I, NESDA, ISCET, Sterling
616 Liberty Street |Who's Who. PHONE:276-632-5045, FAX:276-632-0868
Martinsville Va 24112 |[email protected], ICQ11269732, AIM pjonescet
------------------------------------------------------------------------

If it's "fixed", don't "break it"!

mailto:p[email protected]

<http://www.kimbanet.com/~pjones/default.htm>
<http://www.kimbanet.com/~pjones/90th_Birthday/index.htm>
<http://www.kimbanet.com/~pjones/Fulcher/default.html>
<http://www.kimbanet.com/~pjones/Harris/default.htm>
<http://www.kimbanet.com/~pjones/Jones/default.htm>

<http://www.vpea.org>
 
C

cwhaley

Phillip...

I suspected that what you said was correct from the beginning, but
didn't know how to fix my particular problem until JE pitched in.

I don't know what I'd do without Excel (or something almost identical
to it), but Microsoft's arrogance with respect to international
standards will be their downfall.

It's like the US ignoring the UN and launching unprovoked invasions of
countries wherever and whenever they want to. It tends to backfire
eventually and end badly.
 
J

JE McGimpsey

Phillip Jones said:
The reason why FF or SeaMonkey doing as they do is they follow World
Wide Web Consortium (even MicroSoft is a member though the don't follow
the) standards. So if Safari is ignoring the code its not following
Standards.
Click to expand...

That's a bit hyperbolic.

FF's display of <head> element content is certainly not what the w3c
HTML 4.01 standard prescribes.

It's easy to render compliant documents correctly. This problem exists
whenever an error in standards compliance is encountered (which in this
case is almost certainly MS's fault, but occurs in just about any
generator -I've had to correct DreamWeaver, GoLive, XL, Word, and a host
of other apps's code to achieve compliance). Then the browser designer
has to choose which part of the standard is more important to presenting
the author's intent.

In this case, FF follows a lazy linear parsing right off the cliff, and
Safari correctly applies more sophisticated understanding of content
within the <head>...</head> element, IMO.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads

Need help removing extra TOC text from number lists used as TOC levels 0
Save as Web Page 1
Web query from password protected page? 2
UTF-8 File Opened in Excel from Firefox Browser 1
downloaded excel file won't open 3
Excel to HTML Browser Problems 3
Can hyperlinks open in Firefox? 5
Firefox Compatibility, Pub2007 16

Top