MS#4 – little Suckerfish won't perform...

:rolleyes: 2 dozen links to Tyssens pages not one to yours! I don't want to see Tyssens code (no offence Ty) I seldom refer - if ever - to others code, we need to see the page in question please, ok I know I could get it from the other post but me is lazy.

edit/ sigh if a job needs doing then best do it oneself - Link added for the equally lazy as myself

:bigoops: It's here, sorry :blushing:

The links were for other n00bs like me - not the Glitterati :rolleyes:

Ok so 'red stuf' this is what is commonly known as 'color' and is an effect when light it's the back of the retina so called light is actually made up of a series of wavelengths that radiate at different frequencies differing lengths and it's these that we perceive as color, blue being cold or a very rapid oscillating frequency to red that is a slow long radiant frquency.

Oh very funny...I thought you'd have me bookmarked by now :rolleyes:

Yeah yeah too slow I gone dun edited your post :rolleyes: you might like to remove it though

Yes I thought you'd like the new colour scheme....adds a bit of pizzaz!

Me? Remove one of your bits?

Nevah!!!!!!!!!!

Ok take 2 'red stuff' is the bacj=kground of the ul, you see so much of it due to two factors; first the width of the li @ 10 em is too wide so they wrap to next line expanding height of ul and secondally even if they didn't wrap the padding top and bottom on the ul will force the ul to show.

Warning; 100% width plus padding , together is not a great idea .

Ummm...nope. Wrong answer. At least the menu is on one line in FF2 but there's still a bit extra red on the right no matter what I do.

Yes, I've twigged why T had the width on ul set at 44.5em now - wait a sec and I'll load it - you'll see it makes noooo difference whatsoever.

...off you go then.

...and I reduced the ul li etc from 11em to 10em to fit 6 items and if I make them any smaller I won't be able to write anything in there!!

you can always tweak the font-size, remember that the width of those li elements i.e the sum will dictate the page width to some extent, unless one cares not for having to scroll them onto the screen at smaller widths.

back to 'red stuff' if I widen the viewport to accommodate the li elements on one line I only see the faintest red 1px line to the right edge, which is probably due to rounding values

Eeerrrm...that was the second question in the first post please - what is the best choice seeing I want it centred and to stay centred and visible when I reduce the browser to the #wrapper min-width of 778px?

Odd. I saw about 50px. :? However I've changed it to 0.8em and now it isn't centred anymore Waaaaaaaaaaaaaaaah! I'm back where I started.

Reloaded

Well 778px will dictate then your max width for the nav so it's however many li items you can squeeze in. If you express them in terms of em widths then expect the lists to wrap at narrow widths, possibly better in this instance to fix widths in pixels and limit dimension changes to height only. Of course you could get clever using min-max widths so that the menu keeps the appearance of the same proportions of the viewport at varying widths, but we have to think about IE6 when being clever as it aint.

I was just wondering if that was worth a try....putting the min-max on the #nav I mean...would that work? If I do it the same as I have on the wrapper?

Should I include it in the wrapper?

One thing strikes me which is you might be getting confused with # nav and #nav ul you have both at start of sheet; #nav ul is a child ul of a ul i.e ul#nav

Are you going for the table centering trick? if so get that in place for proper browsers and then work on the inline fix for IE.

For the table technique to work effectively avoid the possibility of the table cell widths changing as this can cause havoc as browsers will adjust the table parent to the width but will struggle to readjust a second time when the width decreases again.

Personally I prefer to avoid the table approach, as FF now supports inline-block you can work it by no width on the parent along with the text-align:center and width and inline block on the li elements, it should then be a short hop to getting it to work in IE6

I'm toadally confused with all these uls and lis - I've never understood them properly - I tend to just get hold of one and try to follow it through

No - no table tricks. Just the GetElementThatNeedsMinWidth that I have used before. That's on the #wrapper now (sidebar and content).

I was wondering if I should stick another one of those on the #menuholder which isn't doing anything at the moment. Would that work?

I've just understood this by reading it several times. I definitely thought it was the ul#nav. So where's my ul#nav then? Where is it implied/inherited? From #nav?

*sigh* shorthand's only helpful when you know what you're doing I'll go and retake my lessons at Listamatic

I was only concerned seeing those two rulesets tht there might have been confusion; obviously ul#nav is essentially the same as #nav I'm just using ul#nav to clarify that #nav is in this cae applied to a ul; seeing the '#nav ul' selector made me think that rules might be applied to it in the belief that it was the top level element in that ul.

I would move the ul#nav construct within #wrapper and use wrappers width restrictions to control it and keep it overall centered.

Oooooh...I think it works! #nav now in wrapper

Of course it presents it's own problems of missing border bits - I've rejigged most of them but scroll down. While there is something else going in the sidebar I can't rely on the content for the border. How do I patch that bit?

Eeerm...I hate to bring this up again but does anyone see the drop downs in IE? :?

You and drop downs in IE6 :rolleyes: , no don't see them so check the script paths are correct, it doesn't look to me as though it's in the root directory.

are you referring to the missing border as a problem? as the left edge is described on the sidebar and that is now of shorter height than the content element that has the other border edges, can you not place the border on the #wrapper instead?

What is occurring with the menuholder group of elements at the bottom? is that a footer menu? if so lets call the parent element by that name just for clarity.

Everyone has a specialty
Yes it does look like they've moved, but they haven't!!
I used to be able to paste the file://localhost/C:/xampp/htdocs/msavers/index.php from the editor's IE - I've learned that lies to me sometimes so I don't trust it anymore - straight into FF (and that still works) and a newly opened IE.

Now the new IE says "what?" and makes me select it from the list of programs so that it can open yet another copy of IE :rolleyes:

Yes I am and No I can't - that's where it used to be - because then it goes up the side of the menu and looks funny/odd. Which is why I didn't put it in there in the first place now I think about it.

That was going to be a footer menu - now I think it's going to be a top button. But I renamed anyway so as not to upset your sensibilities.

New problem - I had height: 30px sitting in #nav (red) to see what was happening. Since it seemed okay, I took it out again. Eeerm ...what happened to the menu :? I've got margin of 15px top and bottom and it's not using it. Does the sidebar and content need to sit in another holder now in order to clear it?

Do I actually need #nav ul? I can't find out what it's doing - I even commented it out and it didn't seem to make any difference once I made sure margin and list-style were in #nav.

That's probably enough to go on with.

#nav ul as written is a descendent selector ( It's the white space between a selector that denotes a descendent selector - as opposed to, say, a child selector which uses a character '>') The descendent selector (everything is deemed a 'selector' in a general sense, whether it be a true html element 'ul', a class or id '#nav', or a 'combinator' such as '>' they all act as items that are selected to have rules applied to) States that the rules are to be applied to this object IF it has a parent or ancestor/antecedent as named; always read the selectors from right to left, right is the selector chosen to receive the rulesets properties working to the left are the objects that this chosen selector/object MUST be nested within, beware though as it is nested to any level no matter how deep the nesting occurs.

You descendent selector group is valid but it will apply rules to your dropdown

• <- this is the ul that will take the rules, if you already specified rules to style the drop down then get rid of this spurious selector/ruleset.

  oops didn't select the last comment to reply to so can't see your other issues... I'll come back to them in a while.

You need overflow:hidden on the #nav as your not containing those floats.

I thought originally that you were going for a centered nav, using floats will not get you this and in a fluid layout this sort of menu is tricky you can try setting a fixed width to the #nav but it will need to be equal to your minimum width for wrapper not as now 800px then it will just auto itself, but it's still not ideal.

Okay - 2nd post first.

I had tried 778px but it wraps that's how I ended up with 800 - I tested it al the way up to 795 as the break point.

I want the top row centered and elastic - I may have to go back to wider drop downs.

Reloaded - see?

Now I'll try to digest your first post.

Get rid of that '#nav ul' your drop downs are styled on this ruleset '#nav li ul' 'nav ul is just dangerous.

Try removing the widths on #nav set the li to display:inline-block; drop down will possibly need to be reset from this value you can then play around with widths on the top level lists. IE would need a different approach with inline on the li and inline-block on the anchors.

Lemme see if I've got this right...

#nav styles apply to anything not specifically overridden
• top level over-riding styles
  nest for drop downs (so if its the same as the top level it can be omitted)
  • specific styling for drop downs

    I think I do understand nesting - it's when bits get skipped in something like this -
    #nav li li { display: block }

    ...that I get a bit crosseyed, but I read it as applying to the drop downs li.
    Yes?

#nav ul gone,
widths on #nav gone, display: inline-block in

reloaded

ETA display: inline-block on #nav li

Unfortunately, it took out the dropdowns so I took overflow:hidden off #nav because I'm not quite sure what else I can do to the li. I've tried just about everything.

Then I brought a new #menuholder in and put the width: 795px on that to see if it would help to move things around - but I don't think it does. Its blue. #nav is red. I put height:30px on both to see where they are. I don't think I can get the top row down to 778 but I can try.

IE6 shows red and blue and no drop downs.
FF2 shows red only with dropdowns.

Had to make the width of the #menuholder 795px to get everything to fit but both IE and FF are shrinking 795 okay though in IE the top row sticks out if you come down further because the wrapper is still set at 778, Doesn't seem to faze FF.

ETAZ: sorry you'll need to read this again - I've explained and changed things some more.

Ignore the above post entirely

IE6 shows red and blue and no drop downs.
FF2 shows red only with dropdowns.
Both seem to shrink and wrap just fine.

Just got the top row down to 780px and changed everything to match.
Reloaded here

Yep the navigation looks fine ,the approach I mentioned to try was but one of many, centering items is a trickier one and combinations of display:inline, and inline-block can work very effectively especially if one wants auto widths.

Try zoom:1 on the menu elements for IE to see if that fixes things

Eeeermm...I tried it on li and li ul but no difference I'm afraid

ETA:
I just took the border off #nav and put it on #nav li ul - look at the difference on the drop down under Home compared to the others. How did that get there? There isn't a border anywhere else in the whole menu.

Look at the markup closely, look at the home link and then examine the nested ul structure for the dropdown you have a second nested ul, looks as though you probably got the code from a two level dropdown example.

Oh I did! I did! I installed Perciformes first and left bits of the html there - I will chase it down. Thanks Hugo

But eeerm...do we actually like this thing?
I'm not sure I do and still no IE drop downs I'll keep looking for them.

Allright then - I've prettyfied it a bit but I'm not entirely sure it's the best option. I've also moved the CSS out to where it's supposed to be.

Maybe I should have the menu I dislike most - inline below the top line?

Like? if that is what is desired then it serves it's purpose.

I would grab the hover2.htc file you might as well be using the latest version it also gives you :focus on all elements, you will need to play around with it's placement, i.e ensure it really is where it's supposed to be, try accessing the file directly doodah.com/hover2.htc to confirm it's available.

Well I really don't like those much.

Do you think it's a better option for this layout is probably the question as you said. Does what we've done look tiny and jumbled? Would you change it? How?

Please use a clearing fix as mentioned before you shouldn't need to set those heights, you seem to be trying to fix problems that don't exist, clear the floated elements then the whole nav will sit correctly above your sidebar and content elements; then you can use text size and/or padding to create a nice spacing top and bottom of the links.

Sort out clearfix clearing for #nav as per above post.

Try making the links bolder and larger as at the moment they are lost, perhaps a slightly different color so that they stand out.

:bigoops: Must've missed the clearfix bit :blushing: I will do that and get the new .htc file too.

Thank you!

ETA:
Alright - I'll much around with the colours too.

I found them!!! I found them!!! Okay you found them
*does a happy dance* - (need a smiley for that please Mr Tony)

Ooooh clever you It was the hover.htc file! For some unfathomable reason I had changed it's name to csshover.htc way back when and of course just copied it - but the script is looking for hover.htc.

Oh bless your little cotton socks! {mwah}

Ah might be me as I name it csshover not sure if that is the original or if I renamed the file.

No I don't think it was you, I've just downloaded the new version and it sez
How To: body { behavior:url("csshover.htc"); }

Well I finally found that the drop down bg colour is the same as the #nav and I can't find how to change one without the other - I just want to change the drop down background.

And I've read though this thread twice and tried to reapply things - but I can't find where you mentioned clearfix - could you point me at it please?

Tomorrow....

Okaaay...I think it was this -

So I put clearfix in and it didn't seem to do the right thing applied to the #nav, (dropped into #content again) so I put it on the #menuholder which seems to work but what do I know

What I think I want now is when you hover over Home, the drop downs should also be tan with white text. Then I can change the hover bg colour. But again, I can't isolate the drop down background from the top nav bar.

ETA: msavers

descendent selectors! if your top level ul has a certain style and it was appearing on further similar elements you would need to overide it. For the nested ul simply do ul ul {background:;} the property is applied to a ul but only if it has a parent or ancestor that is a ul, so the top level ul will not get the new background only the ul that are nested within it but watch out as ALL ul nested will get the property if you wanted to further style another level then you would need to do ul ul ul {background;} this same principle would apply to any element in this type of structure and is often what trips people up.

Sorry Hugo - I must have done something else wrong it doesn't seem to change anything.

:jawdrop: :scared: check that ul list arrangement carefully, especially with a view to attributtes.