Horizontal navs

[geoffb]

Hi all,

We have a horizontal navigation with 9 links that HAVE to all fit in a 900px space.

The problem is on macs (firefox) it is dropping the far right button off.

If we adjust the padding to reduce it around the menu we can bring the dropped off link back up, but this when viewed on other pc's/browsers makes the menu too short for the space.

any ideas?

geoffb

[CSS_Kidd]

If you want to spread the whole menu to match that 900px width, I would do the following...

Measure the width of the longest link (the text), add your padding and then times that width by 9 (all links being the same width)... See how close that is to 900px then add or subtract from the padding. If it is still too big, then reduce the font size.

[glimbeek]

It's wrong in Firefox? Is it also wrong in Firefox on a Windows machine? If so your html/css code is wrong, most likely its wrong because Firefox isn't displaying it correctly in the first place on the mac machine.

Anyway, make it work for Firefox and then load IE specific CSS styles using:

<!--[if IE]>
<link type="text/css" rel="stylesheet" href="iestyles.css">
<![endif]-->

Or use css "hacks", all though I would advice against those.

[geoffb]

Its wrong in firefox on a new imac and right in firefox on a pc and right in IE6-8 on a pc, chrome and safari on pc. Tell you what I have done, you may or may not agree.

Divided the full width of nav div x 9 (number of links) and stated that width in the nav li and removed the nav li a padding.

Seems to work fine on first tests!

Any thoughts?

Geoffb

[rocknbil]

At the risk of sounding like a broken record, does it validate [validator.w3.org]?

Two more cents here, this is also a hack. :-)

<!--[if IE]>
<link type="text/css" rel="stylesheet" href="iestyles.css">
<![endif]-->

Use only as a last resort. Often, if validated, you don't need to . . . but the problem is with FF anyway.

[Fotiman]

2 Thoughts.

1. Try using Firebug to inspect the items. This will tell you exactly what styles are being applied and where they are defined, as well as showing you the layout (where you may learn that a certain item has a default padding or margin).

2. What about margin/padding on the <ul> container? On the <li> elements? And list-style-position?

[glimbeek]

rocknbil, I did not know that/never saw it as a hack.
And go with Fotiman's suggestion, firebug is a life safer!

[rocknbil]

Any conditional or artificial condition you insert to "trick" the browser into doing something besides it's normal rendering is indeed a hack. Put another way, a hack is any "work around" for a problem you don't understand or, rarely, would otherwise an impossible task.

We all know about the CSS star hack and other things done to trick browsers into playing nicely - these types of hacks manipulate actual bugs in the browser to achieve your end result. They don't fix the problem, they work around it.

Another hack, old school methods of inserting Flash (and still in use by Adobe's publish methods.) Moz browsers never really took to the <object> element well and require <embed>. If you put both on the page alone, un-nested, it would validate but then you get two instances to display.

So the hack used to "get around this"

<object id="">
<param name="">
<embed src="">
</object>

Which works, but it's invalid HTML, making use of the bugs inherent in both browsers. Which makes it a hack.

Tabled layout, like it or not, is a hack to get around the fact that pure semantic HTML and CSS lack a similar mechanism, a reliable method of locking content to designated blocks. Once you understand how to work these, there's no need to work around the problem with a table.

IE conditionals by these definitions are hacks. And most of the time - not all, but most - they are used to "fix" a problem the developer doesn't fully understand. Since they don't understand something is throwing them into Quirks mode (or even be aware of it) the summary is something like "It's perfect everywhere except for IE. If there is something I could do just for IE, I'd be done."

Hence, the mind turns to "fixing IE" instead of where it should go, figuring out what you have done to cause IE to misbehave. First stop, of course, it validating the document; second stop, is any of the millions of posts on Just How Screwed Up The IE Box Model Really Is. This leads to what appears to be the simplest solution, apply a conditional hack that is only seen by IE.

Until next year's browser comes out . . . and breaks your hack.

[alt131]

Any conditional or artificial condition you insert to "trick" the browser into doing something besides it's normal rendering is indeed a hack

But surely on that definition, conditional comments are not a hacks?

Conditional comments validate, and the whole point of using them is to send rules that style ie's "normal" rendering so the desired visual display is still achieved. (Like adjustments to account for the box-model.)

I'm not saying using (or having to use) cc's is OK - I also think it best to avoid display issues, but while cc's are undesirable, they are really only effective when the problem is understood, and aren't in the same category as things that don't validate - _underline, *star, or like.

[rocknbil]

Maybe I'm just being absolutist. :-)

Here is how I "see" it. The W3 gives us a standard by which to construct documents. These are defined by spec. You can do this,

<p>blah</p>

But you can't do this.
<ul<li><p>bla</p></li></ul>

If someone were to code that up to get what they think is the desired effect, they are violating spec to obtain a result, which IMO is a hack.

Anything that violates the standard, the ruleset, to activate an effect, is technically a hack. The Wikipedia definition (or at least, my interpretation of it) seems to align with what I'm describing:

Hacking (English verb to hack, singular noun a hack) refers to the re-configuring or re-programming of a system to function in ways not facilitated by the owner, administrator, or designer.

Along comes IE, who says OK, our browser breaks when the standard is followed. So here's a hack you can do to make our browser work like the others. This is why, in my opinion, conditionals are hacks. They only validate because they are wrapped in comments.

An interesting aside is the number of XHTML documents I find with IE conditionals when some of the loudest proponents of XHTML claim you use XHTML because it makes it "cleaner" and "more strict." Oh, the irony . . .

A hack is something you do to meet a condition when the rules set forth don't work. Like red tape over a broken tail light, it's a work around, You won't get a ticket, but it's still a hack. :-)

if ($drunken_friend==$break_tailight) { 
 $dough = cough_up('new taillight'); 
 unless ($dough==$cost_of_repair) { 
  apply_red_tape($lowlife_friends); 
 } 
 return $ah_well_it_works; 
} 

Note to mods, it might be a good idea to split this off to it's own thread, it's long since drifted off topic, sorry

[geoffb]

Hi rocknbil,

In answer to the validate question, yes it does validate perfectly.

The issue we have had is that when viewing the same page in Firefox for instance on 2 Macs and one pc is:

.1 Mac displays the menu and hover overs from edge to edge

.The other Mac drops off the last button stating there is not enough room for it

.The PC renders the navigation about 10px too short to the right

We cant assign sizes to the li's as some of the button text is 2 long words and some buttons look really close and some far away.

Not sure what the answer is?

geoffb