Extra Space in IE - The Sequel

[fleemo17]

I have another table layout that looks good in all the browsers I've
tested it in *except*, once again, IE on the PC. In IE there's extra
space around some of the table cells making up the layout. Apparently,
the problem lies with the bit of javascript I've used to randomly
display a photo on the page. If I take the javascript out, the pieces
of the layout fit together seamlessly. Put the javascript back in and
gaps appear.

Here's the line of code:
<td colspan="2"><sc ript type="text/javascript"
src="random_hea der.js"></script><noscrip t><img src="images/random1.jpg"
width="268" height="275" alt="Polaroid of Kilee"></noscript></td>

And here's the page:
http://www.kileecooper.com

Any clue why the addition of a javascript reference would add space
around the layout?

Thanks.

-Ray

[Martin Jay]

In message <11************ *********@c74g2 000cwc.googlegr oups.com>,
fl******@comcas t.net writes

I have another table layout that looks good in all the browsers I've
tested it in *except*, once again, IE on the PC. In IE there's extra
space around some of the table cells making up the layout. Apparently,
the problem lies with the bit of javascript I've used to randomly
display a photo on the page. If I take the javascript out, the pieces
of the layout fit together seamlessly. Put the javascript back in and
gaps appear.

Here's the line of code:
<td colspan="2"><sc ript type="text/javascript"
src="random_he ader.js"></script><noscrip t><img src="images/random1.jpg"
width="268" height="275" alt="Polaroid of Kilee"></noscript></td>

The HMTL of the page looks like this here.

<SCRIPT src="The Kilee Cooper Website_files/random_header.j s"
type=text/javascript></SCRIPT>
<NOSCRIPT><IM G height=275 alt="Polaroid of Kilee"
src="The Kilee Cooper Website_files/random1.jpg"
I'm not splitting hairs, though. Just pointing out that </SCRIPT> and
<NOSCRIPT> need to be next to each other, like so:

<SCRIPT src="The Kilee Cooper Website_files/random_header.j s"
type=text/javascript></SCRIPT><NOSCRIP T><IMG height=275
alt="Polaroid of Kilee"
src="The Kilee Cooper Website_files/random1.jpg"
And remove the "\n" from the random_header.j s file, so:

document.write( programs[index] + "\n");

becomes:

document.write( programs[index]);

--
Martin Jay
Phone/SMS: [phone]
Fax: [phone]

[fleemo17]

> And remove the "\n" from the random_header.j s file...<

Martin, you da man! Removing that "/n" did the trick! Thank you!
What the heck was that supposed to do, anyway?

On a side note, the other items you mentioned, like having the <script>
and <noscript> together, etc., it must be an issue of whatever you used
to view the source code, as the actual code does do just that. Here's
the code as it appears in the HTML document:

<script type="text/javascript"
src="random_hea der.js"></script><noscrip t><img src="images/random1.jpg"
width="268" height="275" alt="Polaroid of Kilee"></noscript>

But hey, bottom line is you fixed the problem! Many many thanks! :D

[Harlan Messinger]

fl******@comcas t.net wrote:

And remove the "\n" from the random_header.j s file...<
Martin, you da man! Removing that "/n"

\n, not /n
did the trick! Thank you!
What the heck was that supposed to do, anyway?

Exactly what it did. In all the character strings of all C-like
languages including Javascript, \n = new line, \r = carriage return, \t
= tab, \f = form feed, etc.

[Martin Jay]

In message <11************ **********@r2g2 000cwb.googlegr oups.com>,
fl******@comcas t.net writes

And remove the "\n" from the random_header.j s file...<

Martin, you da man! Removing that "/n" did the trick! Thank you!
Pleased to help. :)
What the heck was that supposed to do, anyway?
\n is new line.
On a side note, the other items you mentioned, like having the <script>
and <noscript> together, etc., it must be an issue of whatever you used
to view the source code

Oh, that's odd. But as you say, it may have been added by one of the
applications I use. :(
--
Martin Jay
Phone/SMS: [phone]
Fax: [phone]

[Richard Gration]

I've resisted until now, but I want to bring up the following point.

Isn't is the case that the HTML specs state that consecutive whitespace
characters (which includes space chars, newlines, carriage returns, ASCII
char 255 etc etc) are to be collapsed to a single whitespace character for
display? I ran into the case where IE (correctly) puts spaces around
each of consecutive <img ...> tags where the HTML source is formatted,
quite naturally for readability, with the tags in separate lines. I had to
turn this:

<table><tr>
<td>
<img src="/images/1.gif>
<img src="/images/2.gif>
</td>
</tr></table>

into this:

<table><tr>
<td><img src="/images/1.gif><img src="/images/2.gif></td>
</tr></table>

in order to eliminate the spaces around the images (in IE).

I have always seen this as one area where IE is correct in its
implementation and browers which DWYM and remove the spaces are in fact
silently changing your source, something MICROS~1 is vilified for
regularly.

Just a thought, corrections appreciated.

Rich

[Alan J. Flavell]

On Thu, 22 Jun 2006, Richard Gration wrote:

Isn't is the case that the HTML specs state that consecutive whitespace
characters (which includes space chars, newlines, carriage returns, ASCII
char 255 etc etc) are to be collapsed to a single whitespace character for
display?
Er, yes, but surely that's not your immediate point...?

/
In order to avoid problems with SGML line break rules and
inconsistencies among extant implementations , authors should not rely
on user agents to render white space immediately after a start tag or
immediately before an end tag.
\
http://www.w3.org/TR/REC-html40/struct/text.html#h-9.1
I ran into the case where IE (correctly) puts spaces around
each of consecutive <img ...> tags where the HTML source is formatted,
quite naturally for readability, with the tags in separate lines.
Let's not get side-tracked by whether this is "correctly" . We have
to code for the browsers that are out there, not for some ideal
SGML-conforming user agent.
I had to turn this: .... into this:

<table><tr>
<td><img src="/images/1.gif><img src="/images/2.gif></td>
</tr></table>

in order to eliminate the spaces around the images (in IE).
You're aware that inserting linebreaks inside the tags is harmess?
If you want to break lines up for source code readability, you can
have e.g:

<td><img src="/images/1.gif<img src="/images/2.gif
</td>
and get the same results.

Routine whine: you need alt attributes with your img tags. Again
these could usefully be broken for source readability, a la:

<td><img src="/images/1.gif
alt="providing a meaningful text mode alternative for the purpose 1"<img src="/images/2.gif alt="providing a meaningful text mode alternative for the purpose 2"</td>
but from past experience I would advise against line breaks inside
alt= strings (and title= strings and so on).
I have always seen this as one area where IE is correct in its
implementation and browers which DWYM and remove the spaces are in
fact silently changing your source, something MICROS~1 is vilified
for regularly.

See
http://www.w3.org/TR/REC-html40/appe...es-line-breaks
before reaching a final conclusion.

[Andreas Prilop]

On Thu, 22 Jun 2006, Richard Gration wrote:

(which includes space chars, newlines, carriage returns,
ASCII char 255 etc etc)

What?

[Alan J. Flavell]

On Thu, 22 Jun 2006, Andreas Prilop wrote:

On Thu, 22 Jun 2006, Richard Gration wrote:

(which includes space chars, newlines, carriage returns,
Oh yes, syntactic white space is defined in
http://www.w3.org/TR/REC-html40/struct/text.html#h-9.1
ASCII char 255 etc etc)

What?

well spotted! I must have been asleep when I commented before.

255 is neither ASCII nor white space.

As well as being high on the long-standing Prilop hit-list (not far
below the Belgian code translation table...). SCNR.

[Richard Gration]

On Thu, 22 Jun 2006 14:38:32 +0100, Alan J. Flavell wrote:

On Thu, 22 Jun 2006, Richard Gration wrote:

Isn't is the case that the HTML specs state that consecutive whitespace
characters (which includes space chars, newlines, carriage returns,
ASCII char 255 etc etc) are to be collapsed to a single whitespace
character for display?
Er, yes, but surely that's not your immediate point...?

I was stating it to give context to what follows.
/
In order to avoid problems with SGML line break rules and inconsistencies
among extant implementations , authors should not rely on user agents to
render white space immediately after a start tag or immediately before an
end tag.
\
http://www.w3.org/TR/REC-html40/struct/text.html#h-9.1
I didn't know the SGML "must" about whitespace which you
reference at the end of this reply. While I appreciate the point you make
here, the contrapositive (I think that's the term) is my main point:
Authors should rely on user agents not to render whitespace after a start
tag or before an end tag if no whitespace is present.
We have to
code for the browsers that are out there, not for some ideal
SGML-conforming user agent.

Heh. Surely the biggest source of pain (or one of) in writing documents
for user agents.

<SNIP fair comments>

I have always seen this as one area where IE is correct in its
implementation and browers which DWYM and remove the spaces are in fact
silently changing your source, something MICROS~1 is vilified for
regularly.

See
http://www.w3.org/TR/REC-html40/appe...es-line-breaks
before reaching a final conclusion.

Interesting. However ...

There are 3 whitspace regions in:

<td>
<img ...>
<img ...>
</td>

Your reference deals with the outer 2, and everything you have mentioned
leads inexorably to the conclusion that the only situation in which
authors can rely on UAs not rendering whitespace between the images is if
there really is no whitespace between the tags. I'm wondering if <img
..../> (hence <img ...></img>) has relevance here, but I can't see it
myself.

The subject of the OP could (should?) be stated "missing space in all but
IE".

Rich