Here's what I am trying to do:
(Names represent CSS classes.)
I want to create a photo gallery.  I want the entire gallery to be
surrounded by a box named PhotoGallery.  I want a fluid placement of
the individual Items within PhotoGallery.  An Item is a box that has
two child boxes, PhotoBox and Caption.  Photobox has an explicit width
and height.  PhotoBox contains an image whose dimensions may vary, but
are constrained to be within PhotoBox's dimensions.  Caption has an
explicit width, but its height is determined by the text inside.
Item's width and height depend on both PhotoBox and Caption.
PhotoGallery's width has two contexts.  In the first context,
PhotoGallery has the width of the viewport.  Items are laid out
fluidly inline, meaning that they need to wrap at the end of each
line.  In the second PhotoGallery width context, there are a fixed
number of Items per line, and the width of PhotoGallery depends on the
width of the lines.  It is assumed that all Items will have equal
widths.

Here is a sketch:

+-(PhotoGallery)-----------------------------------
| +-(Item)---------+  +-(Item)---------+
| | +-(PhotoBox)-+ |  | +-(PhotoBox)-+ |
| | |            | |  | |  XXXXXXXX  | |
| | | XXXXXXXXXX | |  | |  XXXXXXXX  | |
| | | XX(Img1)XX | |  | |  X(Img2)X  | |
| | | XXXXXXXXXX | |  | |  XXXXXXXX  | |
| | |            | |  | |  XXXXXXXX  | |  ...
| | +------------+ |  | +------------+ |
| | +-(Caption)--+ |  | +-(Caption)--+ |
| | | Here is a  | |  | | Here is a  | |
| | | caption.   | |  | | longer     | |
| | +------------+ |  | | caption    | |
| +----------------+  | +------------+ |
|                     +----------------+
|
| +-(Item)---------+  +-(Item)---------+
| | +-(PhotoBox)-+ |  | +-(PhotoBox)-+ |
| | |            | |  | |  XXXXXXXX  | |
| | | XXXXXXXXXX | |  | |  XXXXXXXX  | |
| | | XX(Img3)XX | |  | |  X(Img4)X  | |
| | | XXXXXXXXXX | |  | |  XXXXXXXX  | |
| | |            | |  | |  XXXXXXXX  | |  ...
| | +------------+ |  | +------------+ |
| | +-(Caption)--+ |  | +-(Caption)--+ |
| | | Here is a  | |  | | Here is a  | |
| | | caption.   | |  | | longer     | |
| | +------------+ |  | | caption    | |
| +----------------+  | +------------+ |
|                     +----------------+
|
|         ...                 ...


I cannot seem to create this layout with any combination of inline-
and block-level boxes. I am testing using IE 6.0 and Mozilla Firefox
0.9 (Mozilla 5.0) under Windows 2000 Pro, with the xhtml11.dtd
Doctype.  Feel free to point out errors in my inferences.  References
are taken from the W3 CSS 2.0 Spec (REC-CSS2).

Let's start from the inside out.

Inference: A span with only text inside is a non-replaced inline-level
element.

Reference: 10.2 Content width: the 'width' property:
"This property specifies the content width of boxes generated by
block-level and replaced elements. This property does not apply to
non-replaced inline-level elements. ...The width of a replaced
element's box is intrinsic and may be scaled by the user agent if the
value of this property is different than 'auto'."

Conclusion: PhotoBox and Caption must be block-level elements.
Otherwise, the width of the image would determine the width of
PictureBox, and the width of the text would determine the width of
Caption.  Therefore, I will use divs (which I understand to be basic
block-level elements) to represent them.

By (10.5), I can also explicitly set the height of the PhotoBox div.
By (10.6.3), I know that Caption will be just high enough to contain
all the text.

Now the messy part.  I want to nest PhotoBox and Caption inside
another box, Item.  But inline- or block-level?  If I use block-level,
then the user agent is (probably) going to be greedy and use as much
of the viewport as possible for the width.  So I would have to
explicitly define the dimensions of the div, since CSS sadly
(neglegently?) does not allow me to specify a lazy algorithm for
sizing, but rather leaves this up to the user agent altogether. Of
course I will know the width of the images at design time, so I could
assign explicit dimensions to everything.  I could also "float: left"
the divs to get them to fluidly layout, and have lazy sizing.  But
then, I can't put those floated elements into the PictureGallery box,
*and* the rest of the page contents will not fluidly layout relative
to the floated divs (as in before/after them, not wrapping beside
them).

So then the other option is inline-level.  Just try nesting
block-level elements inside an inline-level element -- doesn't work!!

So is it possible to accomplish what I want using the current box
model?  It seems like a simple set of nested boxes to me, but the more
I read the CSS spec, the more it seems that nesting boxes and fluid
layouts do not mix.

I am sure that many people have posted what they consider to solutions
to "problems" in the CSS spec.  I don't want to make the same mistake,
but I don't seem to be able to size the inline-level boxes and have
them wrap as I would like them to.  And the block-level boxes I can
size can only be lazy-sized by floated, which prohibits them from
being nested inside a box.

-Dustin

Dustin wrote:

> Here's what I am trying to do:
> (Names represent CSS classes.)
> I want to create a photo gallery.  I want the entire
> gallery to be surrounded by a box named PhotoGallery.  I
> want a fluid placement of the individual Items within
> PhotoGallery.  An Item is a box that has two child boxes,
> PhotoBox and Caption.  Photobox has an explicit width and
> height.  PhotoBox contains an image whose dimensions may
> vary, but are constrained to be within PhotoBox's
> dimensions.  Caption has an explicit width, but its height
> is determined by the text inside. Item's width and height
> depend on both PhotoBox and Caption. PhotoGallery's width
> has two contexts.  In the first context, PhotoGallery has
> the width of the viewport.  Items are laid out fluidly
> inline, meaning that they need to wrap at the end of each
> line.  In the second PhotoGallery width context, there are
> a fixed number of Items per line, and the width of
> PhotoGallery depends on the width of the lines.  It is
> assumed that all Items will have equal widths.
>
> Here is a sketch:
>
> +-(PhotoGallery)-----------------------------------
>| +-(Item)---------+  +-(Item)---------+
>| | +-(PhotoBox)-+ |  | +-(PhotoBox)-+ |
>| | |            | |  | |  XXXXXXXX  | |
>| | | XXXXXXXXXX | |  | |  XXXXXXXX  | |
>| | | XX(Img1)XX | |  | |  X(Img2)X  | |
>| | | XXXXXXXXXX | |  | |  XXXXXXXX  | |
>| | |            | |  | |  XXXXXXXX  | |  ...
>| | +------------+ |  | +------------+ |
>| | +-(Caption)--+ |  | +-(Caption)--+ |
>| | | Here is a  | |  | | Here is a  | |
>| | | caption.   | |  | | longer     | |
>| | +------------+ |  | | caption    | |
>| +----------------+  | +------------+ |
>|                     +----------------+
>|
>| +-(Item)---------+  +-(Item)---------+
>| | +-(PhotoBox)-+ |  | +-(PhotoBox)-+ |
>| | |            | |  | |  XXXXXXXX  | |
>| | | XXXXXXXXXX | |  | |  XXXXXXXX  | |
>| | | XX(Img3)XX | |  | |  X(Img4)X  | |
>| | | XXXXXXXXXX | |  | |  XXXXXXXX  | |
>| | |            | |  | |  XXXXXXXX  | |  ...
>| | +------------+ |  | +------------+ |
>| | +-(Caption)--+ |  | +-(Caption)--+ |
>| | | Here is a  | |  | | Here is a  | |
>| | | caption.   | |  | | longer     | |
>| | +------------+ |  | | caption    | |
>| +----------------+  | +------------+ |
>|                     +----------------+
>|
>|         ...                 ...
>
>
> I cannot seem to create this layout with any combination of
> inline- and block-level boxes. I am testing using IE 6.0
> and Mozilla Firefox 0.9 (Mozilla 5.0) under Windows 2000
> Pro, with the xhtml11.dtd Doctype.  Feel free to point out
> errors in my inferences.  References are taken from the W3
> CSS 2.0 Spec (REC-CSS2).
>
> Let's start from the inside out.

Sorry, here's where I stopped reading. Lost my attention.
I have made an example page, showing more or less what you
want, but you have to know, that as long as the items are of
different heights, the wrapping can't happen the way you want.
All the items (picture and caption together) need to be of
equal height to prevent them sliding up to one side of the
viewport.

I did it with little two-celled tables, using the cells to
have the pictures vertically centered in their own little box,
as they aren't all the same height.

Anyway, before I type a longer message than you did:
http://locusmeus.com/test/thumbswithcaptions.html
http://locusmeus.com/test/thumbswit...nscentered.html

Note that in the centered version, because of the
display:inline, the items will lose their equal width in Gecko
browsers. IE displays fine, due to their lack of following the
standards, while Opera does too, due to their support of
inline-table.

hth, despite not having read your complete message.

--
Els
http://locusmeus.com/
Sonhos vem. Sonhos vão. O resto é imperfeito.
- Renato Russo -

Thanks for your reply, Els.  I know what I want to do can be done with
tables, but I was under the impression that css boxes should be used
for aligning content and placing borders around items, while tables
should be reserved for tabular data.  I do not think having numerous
inline tables is the proper use for tables.  Then again, what is the
purpose of an inline table?

Ultimately, what I want is a nested css box solution, without tables.
Can this be done?  From what I see, block-level boxes are the only
boxes that can be dimensioned.  Because they always appear on a line
by themselves relative to their siblings in the document tree, I am
not going to be able to achieve the inline layout I want with boxes.
They can be floated, but this puts them in a special realm where they
aren't inline with the rest of the page's contents.  What really
bothers me is that inline-level boxes cannot be dimensioned, and that
their height is determined by the lineheight of their contents.  Far
be it from me, relatively inexperienced, to question the box model,
but does it really make sense to call something a box, to even put a
border around it, and then define its height to be the lineheight of
its content area, allowing inline-level boxes' borders to overlap when
the line wraps?

Is there a distinction between an inline box that segments, like the
popular <em> example when it is broken at the end of the line and part
of it wraps, and an inline box that is atomic -- does not segment when
it only partially fits on a line, but rather wraps as a whole?  If I
put spans side-by-side with no whitespace, they dont't wrap.  If I add
whitespace, they will wrap, but the whitespace affects horizontal
positioning.  If I put a <br> inside of a <span>, the <span> segments
(and not even according to the CSS2 spec in IE6).  I want an inline
box that doesn't segment!  Like a table cell!  I can put an entire
paragraph of text in a table cell, and the cell lazy-sizes to the
text.  Can someone provide some insight?

I really hope someone can show me how to do this because I am really
starting to hate what is going on with CSS layout.

Els <els.aNOSPAM@tiscali.nl> wrote in message news:<Xns9514529715269Els@130.133.1.4>...[col
or=darkred]
> Dustin wrote:
> 
>
> Sorry, here's where I stopped reading. Lost my attention.
> I have made an example page, showing more or less what you
> want, but you have to know, that as long as the items are of
> different heights, the wrapping can't happen the way you want.
> All the items (picture and caption together) need to be of
> equal height to prevent them sliding up to one side of the
> viewport.
>
> I did it with little two-celled tables, using the cells to
> have the pictures vertically centered in their own little box,
> as they aren't all the same height.
>
> Anyway, before I type a longer message than you did:
> http://locusmeus.com/test/thumbswithcaptions.html
> http://locusmeus.com/test/thumbswit...nscentered.html
>
> Note that in the centered version, because of the
> display:inline, the items will lose their equal width in Gecko
> browsers. IE displays fine, due to their lack of following the
> standards, while Opera does too, due to their support of
> inline-table.
>
> hth, despite not having read your complete message.[/color]

On 26 Jun 2004 11:03:50 -0700, Dustin <wasteheap@email.com> wrote:

> I know what I want to do can be done with
> tables, but I was under the impression that css boxes should be used
> for aligning content and placing borders around items, while tables
> should be reserved for tabular data.

Picture and caption are arguably tabular data. Sure, one could argue that
it might not be, but there's a relationship in the column, you're giving
different information about the same thing. Unless you're really
uncomfortable, I'd think a table is fine.

Dustin wrote:

> Thanks for your reply, Els.  I know what I want to do can
> be done with tables, but I was under the impression that
> css boxes should be used for aligning content and placing
> borders around items, while tables should be reserved for
> tabular data.  I do not think having numerous inline tables
> is the proper use for tables.  Then again, what is the
> purpose of an inline table?
>
> Ultimately, what I want is a nested css box solution,
> without tables. Can this be done?  From what I see,
> block-level boxes are the only boxes that can be
> dimensioned.  Because they always appear on a line by
> themselves relative to their siblings in the document tree,
> I am not going to be able to achieve the inline layout I
> want with boxes. They can be floated, but this puts them in
> a special realm where they aren't inline with the rest of
> the page's contents.

Can you explain what you mean by that? If you manage div boxes
of equal height and width, I don't see why floating them would
not do what you want. The only reason I used tables is that I
wanted the pictures vertically centered within their little
square place.

> What really bothers me is that
> inline-level boxes cannot be dimensioned, and that their
> height is determined by the lineheight of their contents.
> Far be it from me, relatively inexperienced, to question
> the box model, but does it really make sense to call
> something a box, to even put a border around it, and then
> define its height to be the lineheight of its content area,
> allowing inline-level boxes' borders to overlap when the
> line wraps?

I think you can define the height of a div just fine, without
being limited to the contents.

> Is there a distinction between an inline box that segments,
> like the popular <em> example when it is broken at the end
> of the line and part of it wraps, and an inline box that is
> atomic -- does not segment when it only partially fits on a
> line, but rather wraps as a whole?  If I put spans
> side-by-side with no whitespace, they dont't wrap.  If I
> add whitespace, they will wrap, but the whitespace affects
> horizontal positioning.  If I put a <br> inside of a
> <span>, the <span> segments (and not even according to the
> CSS2 spec in IE6).  I want an inline box that doesn't
> segment!  Like a table cell!

Then use a table cell! :-)

> I can put an entire paragraph
> of text in a table cell, and the cell lazy-sizes to the
> text.  Can someone provide some insight?
>
> I really hope someone can show me how to do this because I
> am really starting to hate what is going on with CSS
> layout.

[laaaarge snip]

You can use divs for what you want, floating divs, with a set
width and height, or you can use small tables, also with a set
height and width. Or I just don't understand what you want.

And about the use of small tables: what is wrong with a series
of two celled tables, if you would need 3 divs to replace each
table?

--
Els
http://locusmeus.com/
Sonhos vem. Sonhos vão. O resto é imperfeito.
- Renato Russo -

Els <els.aNOSPAM@tiscali.nl> wrote in message news:<Xns9514CFA579AF5Els@130.133.1.4>...[col
or=darkred]
> Dustin wrote: 
>
> Can you explain what you mean by that? If you manage div boxes
> of equal height and width, I don't see why floating them would
> not do what you want. [snip][/color]

Sure :)  I develop components that I want to plop right into an empty
web page, an existing design, or another component.  When you float
things, if there is content in the page and unless the content is
floated in its own box, then the content will wrap around the floated
elements.  If adding a component means I have to make changes to the
rest of the page to make it work, then the component is not "loosely
coupled", and is not really a component, more like a nonreusable
solution (hack).  Also, when you float the divs, you lose the ability
to nest those divs in another box (and no, you can't float inside a
float; there is only one "float space").  Hence, I can't embed this
component in another component, which is baaaad for me.

> 
>
> I think you can define the height of a div just fine, without
> being limited to the contents.

A div is not an inline-level box.  It is block-level.  Try getting
more than one div on the same horizontal line without floating (or
using table cells, or setting "display: inline", which really makes it
a span).   Also try to get a div to lazy-size (shrinkwrap) to its
contents like an inline-level box without floating (or javaScript).
Spans are inline-level boxes.  Have you ever seen two spans atop each
other when the line wraps?  The line height for the contents of inline
boxes is much smaller than the area of their borders when they have
padding.  The spans' bordered areas overlap! Have you ever seen
someone do layout with spans?  No, because they segment and because
they can't be sized (they take the size of their contents, explicit
dimensions are ignored per CSS2 spec).  So there is no inline atomic
box, just the table cell.

> 
>
> Then use a table cell! :-)

I likely will.  This is one of those moments where I shake my head in
disgust at the stupid CSS box model and wonder how the authors expect
us to stop using table cells for layout when CSS does not provide us
real alternatives.

> 
>
> [laaaarge snip]
>
> You can use divs for what you want, floating divs,
> with a set width and height,

Can't be nested = not loosely coupled.

> or you can use small tables, also with a set
> height and width.

Can be nested; are loosely coupled; will likely use this method.

> Or I just don't understand what you want.

I want to know why CSS boxes are so useless.

>
> And about the use of small tables: what is wrong with a series
> of two celled tables, if you would need 3 divs to replace each
> table?

Because I have

<table>
<tr>
<td>
</td>
</tr>
<tr>
<td>
</td>
</tr>
</table>

instead of just

<div>
<div>
</div>
<div>
</div>
</div>

I would never describe the organization of my data in the former way
in an XML document, so why would I want to do it in an XHTML document?

Dustin wrote:

> Els <els.aNOSPAM@tiscali.nl> wrote in message
> news:<Xns9514CFA579AF5Els@130.133.1.4>... 
>
> Sure :)  I develop components that I want to plop right
> into an empty web page, an existing design, or another
> component.  When you float things, if there is content in
> the page and unless the content is floated in its own box,
> then the content will wrap around the floated elements.  If
> adding a component means I have to make changes to the rest
> of the page to make it work, then the component is not
> "loosely coupled", and is not really a component, more like
> a nonreusable solution (hack).  Also, when you float the
> divs, you lose the ability to nest those divs in another
> box (and no, you can't float inside a float; there is only
> one "float space").  Hence, I can't embed this component in
> another component, which is baaaad for me.

I understand that. But it is surely possible to make a box, in
which you float items, and use a clear:both div below those
items, so they really all stay in that box. But yes, that
complete box can't easily be floated, or put next to other
floated objects.
 
>
> A div is not an inline-level box.  It is block-level.  Try
> getting more than one div on the same horizontal line
> without floating (or using table cells, or setting
> "display: inline", which really makes it a span).   Also
> try to get a div to lazy-size (shrinkwrap) to its contents
> like an inline-level box without floating (or javaScript).
> Spans are inline-level boxes.  Have you ever seen two spans
> atop each other when the line wraps?  The line height for
> the contents of inline boxes is much smaller than the area
> of their borders when they have padding.  The spans'
> bordered areas overlap! Have you ever seen someone do
> layout with spans?  No, because they segment and because
> they can't be sized (they take the size of their contents,
> explicit dimensions are ignored per CSS2 spec).  So there
> is no inline atomic box, just the table cell.

Got it :-)
 
>
> I likely will.  This is one of those moments where I shake
> my head in disgust at the stupid CSS box model and wonder
> how the authors expect us to stop using table cells for
> layout when CSS does not provide us real alternatives.

hmm...
I sometimes shake my head (although not in disgust) at what
people want ;-)

I have used floated inline-tables which do exactly what I
want, inside a box in a page, with no problems, I also have
used (on other pages) inline images, and also (yet another
page) floated images next to other floats, and yes, sometimes
it was difficult, but in the end I got what I wanted.
 
>
> Can't be nested = not loosely coupled.

Stop wanting to nest floats ;-)
 
>
> Can be nested; are loosely coupled; will likely use this
> method.
> 
>
> I want to know why CSS boxes are so useless.

I don't think they are, they just won't behave like a table,
but hey, neither do my chairs :-)
 
>
> Because I have
>
> <table>
>   <tr>
>     <td>
>     </td>
>   </tr>
>   <tr>
>     <td>
>     </td>
>   </tr>
> </table>
>
> instead of just
>
> <div>
>   <div>
>   </div>
>   <div>
>   </div>
> </div>
>
> I would never describe the organization of my data in the
> former way in an XML document, so why would I want to do it
> in an XHTML document?

Cause you don't want a complete table layout, yet floating
items in which a picture and some text stay at a certain fixed
height and distance from each other :-)

I have seen examples of floating
<div>
<div>
</div>
<div>
</div>
</div>
but they contained pictures of equal height and width.
Which of course also is an option, but maybe not what you're
after. Plus it has the same disadvantages as floating tables
of course.

--
Els
http://locusmeus.com/
Sonhos vem. Sonhos vão. O resto é imperfeito.
- Renato Russo -

Els <els.aNOSPAM@tiscali.nl> wrote in message news:<Xns95158F60F3DF7Els@130.133.1.4>...[col
or=darkred]
> hmm...
> I sometimes shake my head (although not in disgust) at what
> people want ;-)[/color]

LOL!

>
> Stop wanting to nest floats ;-)

*grin* I don't.  I would like to see more flexibility for nesting
inline boxes without using float.

> Cause you don't want a complete table layout, yet floating
> items in which a picture and some text stay at a certain fixed
> height and distance from each other :-)

The box model defines padding, borders, and margins.  These alone
(provided boxes played nicely) would be enough to do what I want.

Well, thanks for your help.  I appreciate it!  I think the
shortcomings with CSS boxes are due to "if it ain't broke...".  I'm
too much of an idealist sometimes :-P

I found what I wanted.  CSS 2.1 defines "display: inline-block;",
which gives the atomic inline box I described when applied to a <span>
in both IE6 and Firefox 0.9.  These boxes can be freely nested.  I
guess someone agreed with me.

BTW, I used the following code in a test:

<style type="text/css">
span {
display: inline-block;
border: solid 1px black;
padding: 5px;
margin: 5px;
}
</style>

<span>
<span>
<span>
test
</span>
<span>
test
</span>
</span>
<span>
<span>
test
</span>
<span>
test
</span>
</span>
</span>

When I use "padding: 0;" in IE6, margins do not collapse.  However,
the margins collapse in Firefox even when padding is used on the spans
(making the margins no longer "adjoining") as in the given code.  This
is contrary to the spec in both cases, is it not?

-Dustin

wasteheap@email.com (Dustin) wrote in message news:<76497475.0406271451.80be94e@posting.goo
gle.com>...
> Els <els.aNOSPAM@tiscali.nl> wrote in message news:<Xns95158F60F3DF7Els@13
0.133.1.4>... 
>
> LOL!
> 
>
> *grin* I don't.  I would like to see more flexibility for nesting
> inline boxes without using float.
> 
>
> The box model defines padding, borders, and margins.  These alone
> (provided boxes played nicely) would be enough to do what I want.
>
> Well, thanks for your help.  I appreciate it!  I think the
> shortcomings with CSS boxes are due to "if it ain't broke...".  I'm
> too much of an idealist sometimes :-P

nevermind. CSS 2.1 is still a candidate rec.; mozilla browser hasn't
implemented inline-block yet.

wasteheap@email.com (Dustin) wrote in message news:<76497475.0407271218.3dc0051d@posting.go
ogle.com>...
> However,
> the margins collapse in Firefox even when padding is used on the spans
> (making the margins no longer "adjoining") as in the given code.  This
> is contrary to the spec in both cases, is it not?
>