Why the gap on the right side of the image?

Hello,

I have *almost* successfully implemented the CSS rollovers described
by Dan Cederholm at his SimpleBits web site
(http://www.simplebits.com/notebook/2...rollovers.html)

My page is here: http://www.lynngoldstein.com/sarah/test.htm

Things seem to work alright, but I am having trouble with the position
of the very first GIF file in the menu bar because it is separated
from the rest of the GIFs by a larger white gap on its right edge. I
cannot figure out the source of this inconsistency and was wondering
if someone with a fresh set of eyes could please tell me what is going
on?

Thank you,
-M

On Mon, 15 Nov 2004 14:33:46 -0800, mercurius_1 (AT) yahoo (DOT) com (Mercury
Mercurius) wrote in message
<3f0ef26.0411151433.4e8b9255 (AT) posting (DOT) google.com>:

Hello,

I have *almost* successfully implemented the CSS rollovers described by
Dan Cederholm at his SimpleBits web site
(http://www.simplebits.com/notebook/2...rollovers.html)

My page is here: http://www.lynngoldstein.com/sarah/test.htm

Things seem to work alright, but I am having trouble with the position
of the very first GIF file in the menu bar because it is separated from
the rest of the GIFs by a larger white gap on its right edge. I cannot
figure out the source of this inconsistency and was wondering if someone
with a fresh set of eyes could please tell me what is going on?

Remember this site well, it is your friend...

http://validator.w3.org

Your site isn't valid XHTML so it wont render properly. I haven't got
round to writing pages in XHTML yet so can't help you further.

--
FZS600 - Silver/Black
GS125 - Black/Rust
Ford 100E Prefect - Black, naturally
Whisky - Aberlour Cask Strength

PDannyD wrote:

Things seem to work alright, but I am having trouble with the position
of the very first GIF file in the menu bar because it is separated from
the rest of the GIFs by a larger white gap on its right edge. I cannot
figure out the source of this inconsistency and was wondering if someone
with a fresh set of eyes could please tell me what is going on?
snip

The home_button graphic is 89px wide while the rest of the buttons are
90px wide, and the right edge of the graphic is white, 1px wide. Making
it 90px wide and changing the white to match the correct colors fixed it
on my machine in IE6, Netscape 7.2 .

Mike

On Tue, 16 Nov 2004 03:19:38 +0100, Christoph Paeper
<christoph.paeper (AT) nurfuerspam (DOT) de> wrote:

Better yet, he should just use HTML*4.01.

Then you talk him out of it.

"Alan J. Flavell" <flavell (AT) ph (DOT) gla.ac.uk> a écrit dans le message de
news:Pine.LNX.4.61.0411161022350.2917 (AT) ppepc56 (DOT) ph.gla.ac.uk

it hardly matters whether you call it ascii,
iso-8859-anything, or utf-8, since they're indistinguishable in the
absence of any octet above 255

Didn't you meant by the absence of any octet above 127 (0x7F) ?

On Thu, 18 Nov 2004, Pierre Goiffon wrote:

"Alan J. Flavell" <flavell (AT) ph (DOT) gla.ac.uk> a écrit dans le message de
news:Pine.LNX.4.61.0411161022350.2917 (AT) ppepc56 (DOT) ph.gla.ac.uk
it hardly matters whether you call it ascii,
iso-8859-anything, or utf-8, since they're indistinguishable in the
absence of any octet above 255

Didn't you meant by the absence of any octet above 127 (0x7F) ?

Yes, of course. Sheer carelessness on my part, sorry.

On Tue, 16 Nov 2004 10:30:43 +0000, "Alan J. Flavell"
<flavell (AT) ph (DOT) gla.ac.uk> wrote:

[... I have noted the correction of '255' to be '127' ...]

Although if you code your page in us-ascii only,
then - as far as rendering is concerned, and ignoring
the shortcomings of NN4.* versions - it hardly matters
whether you call it ascii, iso-8859-anything, or utf-8,
since they're indistinguishable in the absence of any
octet above 255.

Although the "pure ASCII" approach to page authoring could be said to be
correct in theory; should it not be mentioned that it is the ASCII range
of code points '32' - '126' that is the part that is of practical use.

Starting from the back to look at '127' that one is a control character
of sorts, with its roots in the old punched paper tape era where the
only option available to erase a character already punched on tape was
to punch out all the other available hole positions too and dedicate a
patter of seven holes in the tape to mean "this character position has
been deleted and should not be sent".

AFAIK there is no practical use of code point 127 in an HTML page unless
it could be found some where that it is specified to have some defined
function inside a 'PRE' element?

Like wise; outside of a possible use inside a 'PRE' element (I only know
of code points '9', '10' and '13') anything below code '32' is of
limited use for practical HTML authoring too.

--
Rex

On Thu, 18 Nov 2004, Jan Roland Eriksson wrote:

Starting from the back to look at '127' that one is a control
character

Yes, 127 is a control character, no doubt about that, and AFAIR the
SGML declaration for HTML says that it's not used.

of sorts, with its roots in the old punched paper tape era where the
only option available to erase a character already punched on tape was
to punch out all the other available hole positions too

I've got a hand punch in the archives somewhere, though the
splicer somehow went missing ;-)

Like wise; outside of a possible use inside a 'PRE' element (I only know
of code points '9', '10' and '13') anything below code '32' is of
limited use for practical HTML authoring too.

Less useful than "limited", I think. Check that SGML declaration for
HTML again...?

But that wasn't the point at issue in the previous posting. These
control characters are still the same characters in iso-8859-anything,
and in utf-8, as they are in ascii. And of as much (or as little) use
in HTML, no matter which encoding is in use.

all the best