Problem with height of Nav Bar with image in Opera 6.05

I'm just getting into using CSS and I'm having a problem getting Opera
to display a Navigation Bar in the same way as IE6. Can someone
please point me in the right direction?

The site I'm working on can be seen at
http://www.budbury.co.uk/itel/index.htm

In Opera 6.05 the Nav Bar image floats behind the content division that
follows the navbar.

In IE6 the image is displayed as part of the navbar division with the
content following after. (this is the behavior I want)

I think it is to do with using the Tantek Celik hack incorrectly, but
I'm not sure as I'm using O6.05. A few pointers would be appreciated.

Many thanks Robert
==================
This is the bit of HTML:
<div id="navbar">
<span class="orange">&nbsp;&nbsp;›Home</span>
<a href="telephony.htm">›Telephony</a>
<a href="networking.htm">›Networking</a>
<a href="cabling.htm">›Structured Cabling</a>
<a href="contact.htm">›Contact Us</a>
&nbsp;&nbsp;&nbsp;<span class="grey">CALL US</span><span
class="white"> 01225 787 300</span><br>
<img align=absmiddle src="images/navbar.jpg" width="735" height="154"
alt="Solution for Business Communications"> </div>

This is the part of CSS style sheet:
#navbar {
font-weight: bold;
font-size: 14px;
white-space: nowrap;
margin:0px 10px 0px 20px;
padding:0px 0px 0px 0px;
/* For IE5/Win's benefit height = [correct height] + [top padding] +
[top and bottom border widths] */
height:16px; /* 16px + 0px + 2px = 0px */
border-style:solid;
border-color:black;
border-width:1px 0px; /* top and bottom borders: 1px; left and right
borders: 0px */
line-height:16px;
background-color:#3a8bff;

/* Here is the ugly brilliant hack that protects IE5/Win from its own
stupidity.
Thanks to Tantek Celik for the hack and to Eric Costello for
publicizing it.
IE5/Win incorrectly parses the "\"}"" value, prematurely closing the
style
declaration. The incorrect IE5/Win value is above, while the correct
value is
below. See http://glish.com/css/hacks.asp for details. */
voice-family: "\"}\"";
voice-family:inherit;
height:18px; /* the correct height */
}
/* I've heard this called the "be nice to Opera 5" rule. Basically, it
feeds correct
length values to user agents that exhibit the parsing error exploited
above yet get
the CSS box model right and understand the CSS2 parent-child selector.
ALWAYS include
a "be nice to Opera 5" rule every time you use the Tantek Celik hack
(above). */
body>#Header {height:16px;}

On Tue, Jul 15, Robert Lapes inscribed on the eternal scroll:

This is the bit of HTML:
div id="navbar"
span class="orange">&nbsp;&nbsp;›Home</span

The Unicode character 155 decimal is unused in HTML, as are all of the
control characters from 127 to 159 inclusive.

font-size: 14px;

px font size units? - NOT in a WWW context, please!

"Alan J. Flavell" <flavell (AT) mail (DOT) cern.ch> wrote

On Tue, Jul 15, Robert Lapes inscribed on the eternal scroll:

This is the bit of HTML:
div id="navbar"
span class="orange">&nbsp;&nbsp;›Home</span

The Unicode character 155 decimal is unused in HTML, as are all of the
control characters from 127 to 159 inclusive.

font-size: 14px;

px font size units? - NOT in a WWW context, please!
Thanks for the comments:

Did you have problems seeing the &#155 character?
I was lazy and just used my editor to insert the character.
I can see that &#62 or &gt give a similar character - although they
are not the same as &#155.
What about &#8658 or &raquo, is it safe to use these characters.

I agree that using px as a font-size isn't desirable, however I wanted
to predict the navbar height so I could position the menu correctly.
in this instance changing from px to em or pt - does not fix the
problem with the nav bar image in O6.05. But I do accept it is not an
ideal solution - I will try harder - thanks.
Robert
------

On Tue, Jul 15, Robert Lapes inscribed on the eternal scroll:

Did you have problems seeing the &#155 character?

If the &#155 character existed, it would be CONTROL SEQUENCE
INTRODUCER, but that control character has no use in HTML. So yes,
obviously I have difficulty seeing a character that does not exist
in HTML!

You _meant_ to ask whether I had difficulty in seeing the character
that you were seeing on your browser when it was presented with this
undefined notation, right? Sure, most software these days inevitably
finds it necessary to maintain this much bug-compatibility with the
Empire, but I still say it's best avoided. XML is tightening-up on
this slipshod stuff.

I was lazy and just used my editor to insert the character.

If you had genuinely inserted "the character" then it would have been
a different matter. But it seems your broken software went and
changed "the character" into a non-existent numerical character
reference notation, and _that_ is what I'm complaining about.

What about &#8658 or &raquo, is it safe to use these characters.

What did HTML4 say in 1997? Surely we're most of the way there now...

Which is it to be - a 1997 specification that's now mostly met by
today's browsers, or an ad hoc "looks right to me" specification-
violating notation from the Empire, that has been campaigned against
for even longer than HTML4 existed - and is rightly rejected by
XML-conforming software?

I agree that using px as a font-size isn't desirable, however I wanted
to predict the navbar height so I could position the menu correctly.

Sigh. Doing that only guarantees that it'll break more effectively
when reality doesn't match your assumptions.

in this instance changing from px to em or pt - does not fix the
problem with the nav bar image in O6.05. But I do accept it is not an
ideal solution

But the point I'm trying to get over is that even with your complex
schemes of trying to adapt to the bugs of each browser - even if you
managed to get the result you're aiming for, at the user font setting
that you personally choose, it would still be the wrong solution,
because it's based on pixel-exact sizing. It's about making a web
page, not a glossy printed brochure. Both have their valid place in
the grand scheme of things, but they aren't amenable to the same
techniques of design at this level.

My diagnosis, FWIW, is that this design already has way too
over-complex CSS to be able to work successfully in more than a few
specific browsers at a narrow range of sizes. My counsel, for what
it's worth, is this. Simplify, make more flexible, use techniques
which adapt _themselves_ to the browser situations that they will
encounter, i.e will float the parts of the content into the right
relation with each other, near enough; rather than struggling to
compute everything by dead-reckoning and risking the whole rigid
edifice shattering into bits in browsing situations that differ from
your own.

("Been there, done that"...)

There's parts of your page that already react real well to changes in
browsing situation. But as you've seen, there are still problem
areas.

good luck

By the way, while one's still working on this kind of test page, I'd
recommend to put some visible borders on. I always find it helps to
understand what the browsers are doing:
http://ppewww.ph.gla.ac.uk/~flavell/...yout-diag.html

"Alan J. Flavell" <flavell (AT) mail (DOT) cern.ch> wrote


Alan thank you for your time and comments:

8< Snip

What about &#8658 or &raquo, is it safe to use these characters.

What did HTML4 say in 1997? Surely we're most of the way there now...

Which is it to be - a 1997 specification that's now mostly met by
today's browsers, or an ad hoc "looks right to me" specification-
violating notation from the Empire, that has been campaigned against
for even longer than HTML4 existed - and is rightly rejected by
XML-conforming software?

I'm sorry Alan - I do not understand your comment. I looked on the

W3C web site and could see I shouldn't use &#155 - though many US site
still validate its use. I only found one site in Europe that made it
clear not to use &#155.
The W3C documentation is a little impenetrable... so I could not
decide if I should or should not use &#8658 or &raquo. W3C appeared
to say it was OK.
My aim was to create a pleasing effect to emphasise the navigation bar
text without resorting to using an image.

8< Snip

My diagnosis, FWIW, is that this design already has way too
over-complex CSS to be able to work successfully in more than a few
specific browsers at a narrow range of sizes. My counsel, for what
it's worth, is this. Simplify, make more flexible, use techniques
which adapt _themselves_ to the browser situations that they will
encounter, i.e will float the parts of the content into the right
relation with each other, near enough; rather than struggling to
compute everything by dead-reckoning and risking the whole rigid
edifice shattering into bits in browsing situations that differ from
your own.

("Been there, done that"...)

I am learnly slowly which bits I can control and which bits I cannot.

As part of the learning process, like you've already done, I have to
go there and do that.

I didn't intend to have a pixel perfect page - I'd prefer one that
will flow as it is resized. To save time I started with someone else's
work as a foundation. So now I'm finding out the limitations of the
technology and I'm developing strategies to deal with the problems.

There's parts of your page that already react real well to changes in
browsing situation. But as you've seen, there are still problem
areas.

Thank you, but most of the work has been done before by others - so I
cannot take any real credit for what I've done so far.

good luck

By the way, while one's still working on this kind of test page, I'd
recommend to put some visible borders on. I always find it helps to
understand what the browsers are doing:
http://ppewww.ph.gla.ac.uk/~flavell/...yout-diag.html

Thanks for the tip - I have used it before as recommended by Eric Myer
in his book.

I'm still keen to develop a stategy to get this nav bar image to
display as part of horizontal navigation bar - then get the content
and menu to start below it. Next I was going to investigate use of a
background image to see if Opera is happy with that.

Any more guidance greatfully received.
many thanks
Robert
======

On Wed, Jul 16, Robert Lapes inscribed on the eternal scroll:

Which is it to be - a 1997 specification that's now mostly met by
today's browsers, or an ad hoc "looks right to me" specification-
violating notation from the Empire, that has been campaigned against
for even longer than HTML4 existed - and is rightly rejected by
XML-conforming software?

I'm sorry Alan - I do not understand your comment.

It's based on the W3C's formal specifications.

I looked on the W3C web site and could see I shouldn't use &#155

indeed

- though many US site still validate its use.

In an HTML context, the term "valid" has a precise technical meaning.

If you mean that many US sites offer non-conforming documentation
which advocates its use, then sure, there are all too many folks who
splat whatever they please into their own browsers and assume that
whatever they see must be right. That includes the Empire (who for
some strange reason are also members of the W3C consortium).

The W3C documentation is a little impenetrable... so I could not
decide if I should or should not use &#8658 or &raquo.

The relevant part of the HTML4.01 spec is at
http://www.w3.org/TR/html401/sgml/entities.html#h-24.4

As you can see, the character represented by &raquo; is a normal
Latin-1 character, also known as » - there would be no problem
with rendering that character in any halfways-modern browser. It's
been there since at least HTML3.2.

⇒ is a righwards double arrow (also known as &rArr. In this
case it's less certain that every viewer would be seeing the character
properly: although pretty-much all recent browsers have _support_ for
the &#bignumber; character representation, the success also depends on
whether the users have a font which includes the relevant character. I
think the chances are rather high for this particular character, but
there might still be some gaps.

My aim was to create a pleasing effect to emphasise the navigation bar
text without resorting to using an image.

Sure.

If you want to use a somewhat wider character repertoire than what's
available in Latin-1, but are concerned that users might not have rich
enough Unicode fonts, then a compromise is to limit oneself to the
character repertoire of Windows-1252, see the official cross-mapping
table at
http://www.unicode.org/Public/MAPPIN...OWS/CP1252.TXT

This gives you a couple of dozen often-wanted characters that are
outside of the ISO Latin-1 repertoire. But CP1252 is a proprietary
coding.

This is what the Empire are _attempting_ to do when they write
&#number; references between 128 and 159 decimal: but the correct
HTML4 &#number; references for those characters are their
corresponding Unicode code points. The official Unicode mapping table
gives them in hexadecimal, but your "155" character is this one:

0x9B 0x203A #SINGLE RIGHT-POINTING ANGLE QUOTATION MARK

which in decimal is › (this again can be seen in the HTML4
character list). But you should not need to memorise or even to
continually look-up these characters: your software should be doing
the hack work for you - which, evidently, it is not!

good luck