This is Interesting: Free Magazines for Graphics designers and webmasters  


Home > Archive > Stylesheets > November 2004 > Why the gap on the right side of the image?





You are viewing an archived Text-only version of the thread. To view this thread in it's original format and/or if you want to reply to this thread please [click here]

Author Why the gap on the right side of the image?
Mercury Mercurius

2004-11-19, 12:18 pm

Hello,

I have *almost* successfully implemented the CSS rollovers described
by Dan Cederholm at his SimpleBits web site
(http://www.simplebits.com/notebook/..._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
Alan J. Flavell

2004-11-21, 4:17 am

On Thu, 18 Nov 2004, Pierre Goiffon wrote:

> "Alan J. Flavell" <flavell@ph.gla.ac.uk> a écrit dans le message de
> news:Pine.LNX.4.61.0411161022350.2917@ppepc56.ph.gla.ac.uk
>
> Didn't you meant by the absence of any octet above 127 (0x7F) ?


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

Jan Roland Eriksson

2004-11-21, 4:17 am

On Tue, 16 Nov 2004 10:30:43 +0000, "Alan J. Flavell"
<flavell@ph.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


PDannyD

2004-11-21, 11:18 pm

On Mon, 15 Nov 2004 14:33:46 -0800, mercurius_1@yahoo.com (Mercury
Mercurius) wrote in message
<3f0ef26.0411151433.4e8b9255@posting.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/..._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
mscir

2004-11-21, 11:18 pm

PDannyD wrote:
[color=darkred]
<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
Neal

2004-11-21, 11:18 pm

On Mon, 15 Nov 2004 17:07:07 -0800, mscir <mscir@access4less.net> wrote:

> PDannyD wrote:
>
> <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 .


You totally ignored the directive to validate. http://validator.w3.org/

1) You MUST set a charset. If your server cannot do this, add this to your
head, right after <head>:

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">

2) In XHTML you must close li elements.

<ul id="nav">
<li id="thome"><a href="index.html">Home</a><!-- WHERE'S THE </li> ?????
-->
<li id="tlandscapes"><a href="landscapes/">Landscapes</a><-- ETC.!!!!! ->
<li id="tportraits"><a href="portrait/">Portraits / Figurative</a>
<li id="tflorals"><a href="florals/">Florals</a>
<li id="tnews"><a href="news/">News</a>
<li id="tabout"><a href="about.htm">About</a>
<li id="tcontact"><a href="contact.htm" class="selected">Contact</a>
</ul>

You haven't. Put a </li> after the links in the above on your page, see
what it does. We cannot help further until you eliminate the obvious.

3) While you're at it, in XHTML <br> must be <br /> - fix it.

4) Then validate. http://validator.w3.org/ Be sure the errors of
validation disappear. Also check your CSS with the CSS validator.
http://jigsaw.w3.org/css-validator/ You cannot keep requesting help until
you've used these resources to eliminate the obvious. If you do not
understand the errors, feel free to ask about that.

Then, and ONLY then, if the problem persists, re-post regarding your
positioning wrror.
Christoph Paeper

2004-11-21, 11:18 pm

*Neal* <neal413@yahoo.com>:
>
> 1) You MUST set a charset.


Actually not, but it is really recommended.

> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">


If it was X(HT)ML, UTF-8 would be the default.

> 2) In XHTML you must close li elements.
> 3) While you're at it, in XHTML <br> must be <br /> - fix it.


Better yet, he should just use HTML_4.01.

--
No sig today, my .sig has gone away
The divider stands forlorn, a symbol of the dawn
No sig today, it seems a common sight
But people reading by don't know the reason why
Neal

2004-11-21, 11:18 pm

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

> Better yet, he should just use HTML_4.01.


Then you talk him out of it. ;)
Alan J. Flavell

2004-11-21, 11:18 pm

On Tue, 16 Nov 2004, Christoph Paeper wrote:

> *Neal* <neal413@yahoo.com>:
>
> Actually not, but it is really recommended.


For what - HTML? HTML4.01 asserts that there is no default charset,
which is as close as one can get, without saying it in so many words,
to saying you must set one. CA-2000-02 says that failing to set one
can be a security hazard, which is another strong indication.

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. But the setting might have
side-effects, such as influencing the preferred font, and having
an effect on forms submissions.

>
> If it was X(HT)ML, UTF-8 would be the default.


Confusion here. meta http-equiv has no meaning for XML, nor for XHTML
per se. It's an optional inclusion for compatibility reasons under
the terms of XHTML/1.0 Appendix C, but - as we know - Appendix C is to
some extent self-contradictory, and relies upon "HTML" user agents
failing to implement HTML fully per the rules of SGML.

Pierre Goiffon

2004-11-22, 11:22 pm

"Alan J. Flavell" <flavell@ph.gla.ac.uk> a écrit dans le message de
news:Pine.LNX.4.61.0411161022350.2917@ppepc56.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) ?

Alan J. Flavell

2004-11-22, 11:22 pm

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
Sponsored Links


Copyright 2003 - 2008 forum4designers.com  Software forum  Computer Hardware reviews