Vertically stacking images in a container using float

<div id="wrap">
<div id="header">
<div class="float"><img src="images/header.jpg" alt="header" width="603" height="175" /></div>
<div class="float"><img src="images/top.jpg" alt="top" width="162" /></div>
<div class="float"><img src="images/home.jpg" alt="home" width="162" /></div>
<div class="float"><img src="images/catalogue.jpg" alt="catalogue" width="162" height="25" /></div>
<div class="float"><img src="images/new.jpg" alt="new" width="162" /></div>
<div class="float"><img src="images/shop.jpg" alt="shop" width="162" /></div>
<div class="float"><img src="images/about.jpg" alt="about" width="162" /></div>
<div class="float"><img src="images/bottom.jpg" alt="bottom" width="162" /></div>
</div>

Doctor, we have a really bad case of Div-osis. I'm not sure the patient will survive! And the class-osis is just as bad!

Now, when you float something, you allow a block element to stack ALONGSIDE each other. What you want is that they "stack vertically"-- well, that's actually what divs and other blocks do naturally. If you just removed the float, they will definitely stack vertically!

You may have gotten the float idea from menus written properly-- as a list of links, where each menu item is an LI. LI's are not blocks by default so they are often floated-- and the anchors inside them are not blocks but are also often floated to get around an IE whitespace bug (just display: block sometimes make the links jiggle when hovered over). In fact, most of the time it's best to leave the li's alone, with some goofy statement about colour or something for IE7 to treat it correctly, and floating the a's, whether the menu is horizonal ot vertical. However if the a's (or li's) are floated and need to still stack vertically, then usually the menu was in a box with a fixed with (or the menu itself, a ul most of the time, is a fixed width) and the floats are set to 100% width. This means that while they had the capability of stacking alongside each other, there's no room, so you get the same visual effect as stacked blocks normally are.

So, if you keep that HTML, just stop floating them.

If you want a proper menu (a menu is considered a list of links, so we use lists-- ol's and ul's), you'd want something like this:

<div id="wrap">
<ul id="header">
<li><a href="index.html"><img src="images/home.jpg" alt="home" width="162" /></a></li>
<li><a href="catalogue.html"><img src="images/catalogue.jpg" alt="catalogue" width="162" height="25" /></li>
<li><a href="new.html"><img src="images/new.jpg" alt="new" width="162" /></a></li>
<li><a href="shop.html"><img src="images/shop.jpg" alt="shop" width="162" /></a></li>
<li><a href="about.html"><img src="images/about.jpg" alt="about" width="162" /></a></li>
</ul>

Problem with that code is that your text is locked up in images. Use image replacement instead:

The text is in the link where it should be. The span has your image as a background image. The link (a) is positioned relatively so that the span can be an absolutely positioned child, sitting directly over the text, hiding it. This way, people with images on (most of us) can see the cool image. Those who are blind (like GOOGLE) or those who surf with images off because of dial-up issues (yup, lots of us still use it) still have text to read.

The header.jpg can be set as the background of the ul (the ul is a box so acts like any div), so long as you set a height and width on the ul equal to the size of the image:
ul {
background: url(images/header.jpg) 0 0 no-repeat;
width: 603px;
height: 175px;
}

the first and last li's could be given a class each, so they can hold your top and bottom image:

li.top {
set sizes;
background: url(images/top.jpg) 0 0 no-repeat;
}

Not so! LI is a block element.

Otherwise I thought your post was sensible, but you got that bit wrong.

I beg to differ, Ed!

Not that I've quite figured out what the hell a %flow element is, or what the difference is between a %block and a %flow, esp since first the W3C says in a grave voice: "There be but 2 sorts of elements, %blocks and %inlines." And then like the next line down, calling something a %flow. Wtf? Teh religious scholars, they should clarify what teh Prophets have said.

Then you might want to figure out what %flow does mean! it could well have a bearing on your conjecture here?

and %flow says nothing about the LI element, its what it can contain.

Reread your doctype. what %flow is explained up near the top, just after it defines %block and %inline

Also check out the definition or body (body %block) & p (p %inline) to get a better understanding of what is going on.

and from all that you should be able to deduce what a li element actually is and what it can't be.

I've tried! I'm using this page: http://www.w3.org/TR/html4/struct/lists.html
and then here: http://www.w3.org/TR/html4/sgml/dtd.html#flow
where first I read that there's only block and inline. Looking at what block is got me a list of things that are blocks:

But what they actually are, I never quite find out. I've had this page bookmarked for at least 3 months... I can only use it as a reference, but I can't actually read it.

Like, when I was learning Finnish, I could pick out words in a sentence, yeah this means this and this means that. But I still couldn't read the sentence : )

As I was falling asleep after a too-much-beer party last week I was wondering about that... so was I mistaken all along in thinking that blocks can hold anything while inline can only hold inlines? Is it that blocks can only hold blocks, inlines can only hold inlines, and flows are blocks that can hold both?? And then what's a p, holding only inlines?

The parts I don't have a dictionary for: 0 0, (%block I assume means what it is, or is it what it can contain??) + and + no clue... | (pipe) means and-or, right? last part says what it is in Engrish.

%flow = %block + %inline.

%block is all naturally block elements
%inline is all naturally inline elements

elements which can contain %flow can contain just about any other element

semantic block elements (e.g. P, Hx) can only contain inline elements. In other words they can't be used as containers like LI, DIV and BLOCKQUOTE can. Some containers should only contain block elements (e.g. FORM, BLOCKQUOTE). All of this information is in the DTD document, mostly explained in the comments. E.g.

<!--================== Block level elements ==============================-->
 
<!ENTITY % heading "h1|h2|h3|h4|h5|h6">
<!ENTITY % lists "ul | ol | dl">
<!ENTITY % blocktext "pre | hr | blockquote | address">
 
<!ENTITY % block
     "p | %heading; | div | %lists; | %blocktext; | fieldset | table">
 
<!ENTITY % Block "(%block; | form | %misc;)*">
 
<!-- %Flow; mixes block and inline and is used for list items etc. -->
<!ENTITY % Flow "(#PCDATA | %block; | form | %inline; | %misc;)*">

<!--================== Content models for exclusions =====================-->
 
<!-- a elements use %Inline; excluding a -->
 
<!ENTITY % a.content
   "(#PCDATA | %special; | %fontstyle; | %phrase; | %inline.forms; | %misc.inline;)*">
 
<!-- pre uses %Inline excluding big, small, sup or sup -->
 
<!ENTITY % pre.content
   "(#PCDATA | a | %fontstyle; | %phrase; | %special.pre; | %misc.inline;
      | %inline.forms;)*">
 
<!-- form uses %Block; excluding form -->
 
<!ENTITY % form.content "(%block; | %misc;)*">
 
<!-- button uses %Flow; but excludes a, form and form controls -->
 
<!ENTITY % button.content
   "(#PCDATA | p | %heading; | div | %lists; | %blocktext; |
    table | %special; | %fontstyle; | %phrase; | %misc;)*">

Great post there from Chris.

I must confess that all I really knew was that the LI element can contain block descendants, and that meant "block" to me. Now I see that it is both block and inline!

I confess too that I don't have the patience to read through and understand the actual CSS specs.

Not CSS, but (X)HTML specs. There is no need to read them through. Just look things up from time to time. After a year or two you'll be surprised at your knowledge.

Wait, it's block AND inline?? I asked my husband yesterday and he thought |(pipe) meant "or". Although a flow being a block OR an inline also doesn't make sense, it's one or the other right?

So the %whatever after the element name isn't what it is, but what it can contain? OKay...

Flow mixes... meaning, that it IS a block AND an inline, or that it is an element that can Contain a block or an inline?

I know that some elements like form and blockquote can only hold blocks as direct children but I still don't know why... still like memorising "The cheese is old and moldy, where is the bathroom" in another language, and knowing that by saying that you are getting directions to the bathroom but still not knowing the constructions of the words or the grammar.

Actually, I've ended up using the Florida site for knowing who can be a valid child or parent of something just because it's easier to read: http://learningforlife.fsu.edu/webmaster/references/xhtml/tags/

Maybe I don't have to know why, and just memorise who can do what, but I don't like that.

yes it is intended to impart what the element may contain not what it is strictly and yes the pipe character means 'or'.

yes maybe there is too much overthinking going on!

Now is the original post dealt with? as were doing a good job of hijacking it

And now, to get back OT, as is our wont:

The specs are not all that easy to read. Instructions for reading with some modicum of clue are found here.

When reading the specs, elements are often grouped and given entity names, as the mentioned %flow, %block and %inline. These entities, when part of an element's description are always linked to their definitions. eg.

<!--================== HTML content models ===============================-->
 
<!--
    HTML has two basic content models:
 
        %inline;     character level elements and text strings
        %block;      block-like elements e.g. paragraphs and lists
-->
 
<!ENTITY % block
     "P | %heading; | %list; | %preformatted; | DL | DIV | NOSCRIPT |
      BLOCKQUOTE | FORM | HR | TABLE | FIELDSET | ADDRESS">
 
<!ENTITY % flow "%block; | %inline;">
 
<!--=================== Document Body ====================================-->
 
<!ELEMENT BODY O O (%block;|SCRIPT)+ +(INS|DEL) -- document body -->
<!ATTLIST BODY
  %attrs;                              -- %coreattrs, %i18n, %events --
  onload          %Script;   #IMPLIED  -- the document has been loaded --
  onunload        %Script;   #IMPLIED  -- the document has been removed --
  >
 
<!ELEMENT ADDRESS - - (%inline;)* -- information on author -->
<!ATTLIST ADDRESS
  %attrs;                              -- %coreattrs, %i18n, %events --
  >
 
<!ELEMENT DIV - - (%flow;)*            -- generic language/style container -->
<!ATTLIST DIV
  %attrs;                              -- %coreattrs, %i18n, %events --
  %reserved;                           -- reserved for possible future use -- 
  >
...

cheers,

gary

Now returning you to our regular programming.

Yes but this is not OT :rolleyes:

Anyways just to clarify in plain old english the % is an internal shorthand notation designed to save having to glog the document up with the same repeated longwinded detail, explained once at top of document then referenced thereafter by the shorthand %flow, %block amongst others.

Now to get back on topic, er...

I'm with Poes!

I knew that would happen!

Ah, Tommy sent me a nice, plain-English explanation of how to read the DTD: http://www.autisticcuckoo.net/archive.php?id=2005/05/01/art-of-reading-dtd

I do wish I'd had this several months ago.

As for the original topic, I think I answered it... don't float your divs and they'll stack vertically cause that's what they do.

Well wasn't that nice of Tommy, surprised that you hadn't come across that before seeing as you hang out on that forum.

What Tommy fails to mention which would be helpful is what the syntactical notation used is called.

BNF (Backus–Naur Form) is a formal grammar to express coding and is useful to have a grasp of as you'll then be able to better understand things.

In spoken language "or" often means "exclusive or", its this or its that but its not both.

In logic (and programming) "or" always means "inclusive or", its this, its that or its both.

Computers being quite literal minded and unable to figure things like that out from context (as humans do without conscious thought), we've even had to invent our own little word ("xor") to help us understand how the little beasties think.

Ah, I vaguely remember boolean logic from back when I was building little breadboard circuits and flip-flops... and n' nand n' or n' nor... misspent youth, seeings how I don't remember a bit of it.

Yeah I'm on the forum but I think I would have had to do some digging into the older parts to run into that... I don't visit sites I see in people's sigs most of the time.

He mentions C programmers being familiar with it, and if I had continued reading my ANSI C book that my husband foisted on me (and wants me to read before really embarking on Javascript), then I likely would have understood it better.