Strange behavior with Service Side Include

[silverbob]

I am replacing my Javascript-called files with SSI, and I'm getting an
unexpected result with my page footer. I can really use some help
with this.

The footer contains a copyright (left justified), and page links
(right justfied) all on the same line. After changing to SSI, the
right side links are correct, but the left side copyright looks to be
wrapping to the next line. I can fix this in IE by moving it back up
in line with the links with a "style=marg in-top:-10px", but that
creates undesired results in Firefox.

Here are the details:

First, there is a script that writes a horizontal line and sets up
some stuff:

//<!--
/*Determine if the browser is a Mac browser.*/
if (navigator.appV ersion.indexOf( "Mac") != -1 ) {
/*Write to the Mac browser to the desired links.*/
document.write( '<div id="bottomBarWi thFooter3">' );
}
else {
document.write( '<div id="bottomBarWi thFooter2">' );
}
//-->

#bottomBarWithF ooter2 {
width: 980px;
border-top: 1px solid #ced2d5;
border-bottom: 0px solid #7aff0f;
margin-top: -20px;
background-color: #ffffff;
font-size: 9px;
font-family: Verdana;
color: #003875;
font-weight: bold;
text-align: right;
padding-top: 0px;
}
Then my footer. These are the changes:

From this:

<script type="text/javascript" src="/footer.txt"></script>

(contents of footer.txt)
document.write( '<div id="copyInfoFoo ter">© 1985-2008 Symark
International, Inc. All rights reserved. </div><a href="/sitemap.html"
class="footer15 n">Site Map</a><a href="/support/support.html"
class="footer15 n">Contact Us</a><a href="/company/privacy.html"
class="footer15 ">Privacy Policy/ California Privacy Rights</a><a
href="/index.html" class="footern" >Home</a>')

#copyInfoFooter {
float: left;
color: #7c7c7c;
font-weight: normal;
text-decoration: none;
font-family: Verdana;
color: #003875;
font-weight: bold;
text-align: right;
padding-top: 0px;
}
To this:

<!--#include virtual="/includes/footer.html" -->

(contents of SSI file footer.html)
<div id="copyInfoFoo ter">© 1985-2008 Symark International, Inc. All
rights reserved.</div>
<a href="/sitemap.html" class="footer15 n">Site Map</a><a href="/
support/support.html" class="footer15 n">Contact
Us</a><a href="/company/privacy.html" class="footer15 ">Privacy Policy/
California Privacy
Rights</a><a href="/index.html" class="footern" >Home</a>

[Lars Eighner]

In our last episode,
<f3************ *************** *******@w39g200 0prb.googlegrou ps.com>, the
lovely and talented silverbob broadcast on
comp.infosystem s.www.authoring.html:

I am replacing my Javascript-called files with SSI, and I'm getting an
unexpected result with my page footer. I can really use some help
with this.

I went to the Symark site, and poking around a little, I did not find this
exact footer. Nonetheless, let us reason together. It cannot possibly be
that you use SSI, because SSI is seamless to the browser. It must be that
the SSI text is not *exactly* like the previous script generated text.

You can copy and paste the SSI text into a test document to prove that
SSI is not at fault (which is theoretically impossible anyway, but some
people still need proof that water is wet). So then you have to compare the
served SSI document (i.e. view source) with the script generated source
until you discover what is different.

In particular, some versions of IE are known to not handle some whitespace
(especially newlines) between tags properly. You must make the SSI agree
*exactly* with the script generated text --- including spaces and newlines,
even where they shouldn't count --- to expect consistent results in IE.
A quick examination reveals that the SSI text is not exactly the same
as the script text in reguard to spaces and newlines.

--
Lars Eighner <http://larseighner.com/us****@larseigh ner.com
War on Terrorism: Bad News from the Sanity Front
"There's one thing ... that I do like about Rumsfeld, he's just a little bit
crazy, OK"? --Thomas Friedman, _The New York Times_

[silverbob]

On Jul 31, 3:30 pm, Lars Eighner <use...@larseig hner.comwrote:

In our last episode,
<f3886e1a-8130-4411-a4aa-b8ca90fe6...@w3 9g2000prb.googl egroups.com>, the
lovely and talented silverbob broadcast on
comp.infosystem s.www.authoring.html:

I am replacing my Javascript-called files with SSI, and I'm getting an
unexpected result with my page footer. I can really use some help
with this.

I went to the Symark site, and poking around a little, I did not find this
exact footer. Nonetheless, let us reason together. It cannot possibly be
that you use SSI, because SSI is seamless to the browser. It must be that
the SSI text is not *exactly* like the previous script generated text.

You can copy and paste the SSI text into a test document to prove that
SSI is not at fault (which is theoretically impossible anyway, but some
people still need proof that water is wet). So then you have to compare the
served SSI document (i.e. view source) with the script generated source
until you discover what is different.

In particular, some versions of IE are known to not handle some whitespace
(especially newlines) between tags properly. You must make the SSI agree
*exactly* with the script generated text --- including spaces and newlines,
even where they shouldn't count --- to expect consistent results in IE.
A quick examination reveals that the SSI text is not exactly the same
as the script text in reguard to spaces and newlines.

--
Lars Eighner <http://larseighner.com/use...@larseigh ner.com
War on Terrorism: Bad News from the Sanity Front
"There's one thing ... that I do like about Rumsfeld, he's just a little bit
crazy, OK"? --Thomas Friedman, _The New York Times_

I just reformatted the HTML so that it is exactly like the javascript
text file (minus the "document.write "). It made no difference as I
would expect because HTML does not care how its formatted.

Then, I replaced the SSI call with the exact code being used in the
SSI file, and the footers display differently. Take a look:
http://www.symark.com/test6.html (This is the SSI version)
http://www.symark.com/test7.html (This is the same SSI HTML but
embedded in the page)

Remember. This is in IE.

BTW, when I view the page source, I see a little dot or something
preceding the SSI inserted code. Is this typical?

Regards, Bob

[silverbob]

On Jul 31, 3:30 pm, Lars Eighner <use...@larseig hner.comwrote:

In our last episode,
<f3886e1a-8130-4411-a4aa-b8ca90fe6...@w3 9g2000prb.googl egroups.com>, the
lovely and talented silverbob broadcast on
comp.infosystem s.www.authoring.html:

I am replacing my Javascript-called files with SSI, and I'm getting an
unexpected result with my page footer. I can really use some help
with this.

I went to the Symark site, and poking around a little, I did not find this
exact footer. Nonetheless, let us reason together. It cannot possibly be
that you use SSI, because SSI is seamless to the browser. It must be that
the SSI text is not *exactly* like the previous script generated text.

You can copy and paste the SSI text into a test document to prove that
SSI is not at fault (which is theoretically impossible anyway, but some
people still need proof that water is wet). So then you have to compare the
served SSI document (i.e. view source) with the script generated source
until you discover what is different.

In particular, some versions of IE are known to not handle some whitespace
(especially newlines) between tags properly. You must make the SSI agree
*exactly* with the script generated text --- including spaces and newlines,
even where they shouldn't count --- to expect consistent results in IE.
A quick examination reveals that the SSI text is not exactly the same
as the script text in reguard to spaces and newlines.

--
Lars Eighner <http://larseighner.com/use...@larseigh ner.com
War on Terrorism: Bad News from the Sanity Front
"There's one thing ... that I do like about Rumsfeld, he's just a little bit
crazy, OK"? --Thomas Friedman, _The New York Times_

This little dot I spoke of seems to be the source of my problem. You
can see it when you do a view source from IE, but it doesn't appear in
the source from Firefox.

- Bob

[Lars Eighner]

In our last episode,
<03************ *************** *******@a21g200 0prf.googlegrou ps.com>, the
lovely and talented silverbob broadcast on
comp.infosystem s.www.authoring.html:

On Jul 31, 3:30 pm, Lars Eighner <use...@larseig hner.comwrote:

>In our last episode,
<f3886e1a-8130-4411-a4aa-b8ca90fe6...@w3 9g2000prb.googl egroups.com>, the
lovely and talented silverbob broadcast on
comp.infosyste ms.www.authoring.html:

I am replacing my Javascript-called files with SSI, and I'm getting an
unexpected result with my page footer. I can really use some help
with this.

I went to the Symark site, and poking around a little, I did not find this
exact footer. Nonetheless, let us reason together. It cannot possibly be
that you use SSI, because SSI is seamless to the browser. It must be that
the SSI text is not *exactly* like the previous script generated text.

You can copy and paste the SSI text into a test document to prove that
SSI is not at fault (which is theoretically impossible anyway, but some
people still need proof that water is wet). So then you have to compare the
served SSI document (i.e. view source) with the script generated source
until you discover what is different.

In particular, some versions of IE are known to not handle some whitespace
(especially newlines) between tags properly. You must make the SSI agree
*exactly* with the script generated text --- including spaces and newlines,
even where they shouldn't count --- to expect consistent results in IE.
A quick examination reveals that the SSI text is not exactly the same
as the script text in reguard to spaces and newlines.

--
Lars Eighner <http://larseighner.com/use...@larseigh ner.com
War on Terrorism: Bad News from the Sanity Front
"There's one thing ... that I do like about Rumsfeld, he's just a little bit
crazy, OK"? --Thomas Friedman, _The New York Times_

I just reformatted the HTML so that it is exactly like the javascript
text file (minus the "document.write "). It made no difference as I
would expect because HTML does not care how its formatted.

Then, I replaced the SSI call with the exact code being used in the
SSI file, and the footers display differently. Take a look:
http://www.symark.com/test6.html (This is the SSI version)
http://www.symark.com/test7.html (This is the same SSI HTML but
embedded in the page)

Remember. This is in IE.

BTW, when I view the page source, I see a little dot or something
preceding the SSI inserted code. Is this typical?

No. SSI is seamless to client. However there are/is some nonsense
characters after an few more tabs (than in test7). However the same
characters appear in several other places, so I assume it is some utf-8
dingbat, intentional or otherwise. Anyway, this appears to be the only
utf-8 that is in the document. Is it being served as utf-8? (and you do
know that meta http-equiv is useless, don't you? -- well, not entirely
useless, but has no effect whatever on how the document is served.)
Is the text for the SSI being saved as utf-8?

--
Lars Eighner <http://larseighner.com/us****@larseigh ner.com
War hath no fury like a noncombatant.
- Charles Edward Montague

[Hendrik Maryns]

Op 01-08-08 01:55 heeft Lars Eighner als volgt van zich laten horen:

Is it being served as utf-8? (and you do
know that meta http-equiv is useless, don't you? -- well, not entirely
useless, but has no effect whatever on how the document is served.)

No, I didn’t know that, mind pointing me to an explanation?

Cheers, H.

[Lars Eighner]

In our last episode,
<48********@new s.arcor-ip.de>,
the lovely and talented Hendrik Maryns
broadcast on comp.infosystem s.www.authoring.html:

Op 01-08-08 01:55 heeft Lars Eighner als volgt van zich laten horen:

>Is it being served as utf-8? (and you do
know that meta http-equiv is useless, don't you? -- well, not entirely
useless, but has no effect whatever on how the document is served.)

No, I didn?t know that, mind pointing me to an explanation?

I don't know what you mean by an explanation. The meta http-equiv
tag is useless for determining how a document is served by a server.
The server does not get any information from it, and when the document
comes from a server, neither does the client. It is supposed to help
a client when reading the document as a file (no server involved) by
supplying information that the server would supply if the document were
served. You can't change a served document's mime type or character set
with meta http-equiv because when the document is served that information
is in the http headers, and by the time the meta tag is sent, that ship has
sailed.

--
Lars Eighner <http://larseighner.com/us****@larseigh ner.com
That was Zen; this is Tao.

[silverbob]

On Jul 31, 4:55 pm, Lars Eighner <use...@larseig hner.comwrote:

In our last episode,
<03fc3a18-cdb8-44a0-92d9-978d816e2...@a2 1g2000prf.googl egroups.com>, the
lovely and talented silverbob broadcast on
comp.infosystem s.www.authoring.html:

On Jul 31, 3:30 pm, Lars Eighner <use...@larseig hner.comwrote:

In our last episode,
<f3886e1a-8130-4411-a4aa-b8ca90fe6...@w3 9g2000prb.googl egroups.com>, the
lovely and talented silverbob broadcast on
comp.infosystem s.www.authoring.html:

I am replacing my Javascript-called files with SSI, and I'm getting an
unexpected result with my page footer. I can really use some help
with this.

I went to the Symark site, and poking around a little, I did not find this
exact footer. Nonetheless, let us reason together. It cannot possibly be
that you use SSI, because SSI is seamless to the browser. It must be that
the SSI text is not *exactly* like the previous script generated text.

You can copy and paste the SSI text into a test document to prove that
SSI is not at fault (which is theoretically impossible anyway, but some
people still need proof that water is wet). So then you have to compare the
served SSI document (i.e. view source) with the script generated source
until you discover what is different.

In particular, some versions of IE are known to not handle some whitespace
(especially newlines) between tags properly. You must make the SSI agree
*exactly* with the script generated text --- including spaces and newlines,
even where they shouldn't count --- to expect consistent results in IE.
A quick examination reveals that the SSI text is not exactly the same
as the script text in reguard to spaces and newlines.

--
Lars Eighner <http://larseighner.com/use...@larseigh ner.com
War on Terrorism: Bad News from the Sanity Front
"There's one thing ... that I do like about Rumsfeld, he's just a little bit
crazy, OK"? --Thomas Friedman, _The New York Times_

I just reformatted the HTML so that it is exactly like the javascript
text file (minus the "document.write "). It made no difference as I
would expect because HTML does not care how its formatted.
Then, I replaced the SSI call with the exact code being used in the
SSI file, and the footers display differently. Take a look:
http://www.symark.com/test6.html(This is the SSI version)
http://www.symark.com/test7.html(This is the same SSI HTML but
embedded in the page)
Remember. This is in IE.
BTW, when I view the page source, I see a little dot or something
preceding the SSI inserted code. Is this typical?

No. SSI is seamless to client. However there are/is some nonsense
characters after an few more tabs (than in test7). However the same
characters appear in several other places, so I assume it is some utf-8
dingbat, intentional or otherwise. Anyway, this appears to be the only
utf-8 that is in the document. Is it being served as utf-8? (and you do
know that meta http-equiv is useless, don't you? -- well, not entirely
useless, but has no effect whatever on how the document is served.)
Is the text for the SSI being saved as utf-8?

--
Lars Eighner <http://larseighner.com/use...@larseigh ner.com
War hath no fury like a noncombatant.
- Charles Edward Montague

I don't want this thread to take off in a new direction, but to
address the meta http-equiv issue, when I save the document as HTML
encoding UTF-8 in my editor (MS Expression Web), it puts <meta http-
equiv="Content-Type" content="text/html; charset=utf-8"in the <head>
area.

- Bob

[Lars Eighner]

In our last episode,
<c2************ *************** *******@t1g2000 pra.googlegroup s.com>, the
lovely and talented silverbob broadcast on
comp.infosystem s.www.authoring.html:

On Jul 31, 4:55 pm, Lars Eighner <use...@larseig hner.comwrote:

>Is it being served as utf-8? (and you do
know that meta http-equiv is useless, don't you? -- well, not entirely
useless, but has no effect whatever on how the document is served.)
Is the text for the SSI being saved as utf-8?

I don't want this thread to take off in a new direction, but to
address the meta http-equiv issue, when I save the document as HTML
encoding UTF-8 in my editor (MS Expression Web), it puts <meta http-
equiv="Content-Type" content="text/html; charset=utf-8"in the <head>
area.

The meta http-equiv tag is harmless and may be helpful when the document is
viewed as a file. But it is useless when the document is served. The harm
is that the meta tag might mislead you to think it is enough for a served
document. It isn't. If you don't know the defaults for your server for
sure, you need to AddType *and* AddCharset in your .htaccess .

As I have said elsewhere, the mime type and charset need to be in the http
headers and by the time the meta tag is sent that ship has sailed.

--
Lars Eighner <http://larseighner.com/us****@larseigh ner.com
If it wasn't for muscle spasms, I wouldn't get any exercise at all.

[silverbob]

I finally found a simple solution. This page described my issue,
http://www.w3.org/International/questions/qa-utf8-bom.
By opening my include files in Notepad, changing the encoding from
UTF-8 to ANSI, and resaving, I was able to eliminate the problem.

- Bob