Putting boxes side-by-side

I have a huge pile of open-source PHP, far too big for me to
wrestle it into submission. It generates nested tables
MANY layers deep.

What I am trying to do is extract several small pieces from it and put
each of those in a box (in a new file) and arrange those boxes my way.

The layout I want is (you'll need fixed width font):

+-----+-----+-----+-----+

PGF | PGM | MGF | MGM |
+-----+-----+-----+-----+
father | mother |
+-----------+-----------+
child |
+-----------------------+
child |
+-----------------------+

The stuff in the boxes is very complicated and also includes nested
tables, but I was hoping that making these boxes out of divs, I could
put boundaries on the pieces and then clean them up later.

So the divs, without contents, are
<div class="FGS">

<div class="grandparents" -->

<div class="PGP">
<div class="PGF">
</div><!-- class="PGF" -->
<div class="PGM">
</div><!-- class="PGM" -->
</div><!-- class="PGP" -->

<div class="MGP">
<div class="MGF">
</div><!-- class="MGF" -->
<div class="MGM">
</div><!-- class="MGM" -->
</div><!-- class="MGP" -->

</div><!-- class="grandparents" -->

<div class="parents">

<div class="father">
</div><!-- class="father" -->

<div class="mother">
</div><!-- class="mother" -->

</div><!-- class="parents" -->

<div class="children">
</div><!-- class="children" -->

</div><!-- class="FGS" -->

Here's the CSS I tried (in FireFox on Mac), but all these divs are
stacked up in a single vertical column:
..FGS, .grandparents, .parents, .children, .child
{
width: 100%;
margin: 0;
padding: 0;
}

..PGF, .PGM, .MGF, .MGM
{
width: 25%;
margin: 0;
padding: 0;
}

..father, .mother, .PGP, .MGP
{
width: 50%;
margin: 0;
padding: 0;
}

..PGF, .MGF, .father
{
float: left;
}

..PGM, .MGM, . mother
{
float: right;
}

Obviously trivial to do with a table, but I'd rather not.

Thanks!

--
Wes Groleau

Nobody believes a theoretical analysis -- except the guy who did it.
Everybody believes an experimental analysis -- except the guy who
did it.
-- Unknown

In article <ylzkj.723$Yl.262@trnddc01>,
Wes Groleau <groleau+news (AT) freeshell (DOT) org> wrote:

I have a huge pile of open-source PHP, far too big for me to
wrestle it into submission. It generates nested tables
MANY layers deep.

What I am trying to do is extract several small pieces from it and put
each of those in a box (in a new file) and arrange those boxes my way.

The layout I want is (you'll need fixed width font):

+-----+-----+-----+-----+
| PGF | PGM | MGF | MGM |
+-----+-----+-----+-----+
| father | mother |
+-----------+-----------+
| child |
+-----------------------+
| child |
+-----------------------+

....
div class="grandparents" --

div class="PGP"

Obviously trivial to do with a table, but I'd rather not.

First why would you rather not use a table? Second, if you are
going to post masses of code, why would you not post code that
did something rather than be hopelessly invalid. And third, what
possible benefit are the (wrongly coded) comments for? Of course
a <div class=""PGF"> is a classed div with PGF as the name of the
class.

--
dorayme

dorayme wrote:

Wes Groleau <groleau+news (AT) freeshell (DOT) org> wrote:
I have a huge pile of open-source PHP, far too big for me to
wrestle it into submission. It generates nested tables
MANY layers deep.
...
div class="grandparents" --

div class="PGP"

Obviously trivial to do with a table, but I'd rather not.

First why would you rather not use a table? Second, if you are

The answer to that (besides the usual rants about confusing
blind people) is in that first paragraph.

going to post masses of code, why would you not post code that
did something rather than be hopelessly invalid. And third, what
possible benefit are the (wrongly coded) comments for? Of course

Hopelessly invalid? Wrong comments? Yes, the obvious div you quoted
is a typo. Maybe even the reason it didn't work. But all the rest of
the comments correctly identify the div they are ending. A very
important coding convention if you want any hope of dealing with
"spaghetti HTML" generated by someone else's "spaghetti PHP"

--
Wes Groleau

Is it an on-line compliment to call someone a Net Wit ?

In article <2_Pkj.12695$9t4.2913@trnddc08>,
Wes Groleau <groleau+news (AT) freeshell (DOT) org> wrote:

dorayme wrote:
Wes Groleau <groleau+news (AT) freeshell (DOT) org> wrote:
I have a huge pile of open-source PHP, far too big for me to
wrestle it into submission. It generates nested tables
MANY layers deep.
...
div class="grandparents" --

div class="PGP"

Obviously trivial to do with a table, but I'd rather not.

First why would you rather not use a table? Second, if you are


The answer to that (besides the usual rants about confusing
blind people) is in that first paragraph.

OK Wes, I'm not saying for sure you have no good reason. But I
still cannot see it. Something generates nested tables many
layers deep. What has this quite to do with your particular
problem? You said "What I am trying to do is extract several
small pieces from [this massive convoluted table] and put each of
those in a box (in a new file) and arrange those boxes my way".
So? Why does this preclude you using a table for selected data in
a separate file considering it looks rather like tabular data you
are dealing with? I recall there being a relationship between the
cells, perhaps you might argue it is not really tabular in spite
of the appearance?

going to post masses of code, why would you not post code that
did something rather than be hopelessly invalid. And third, what
possible benefit are the (wrongly coded) comments for? Of course

Hopelessly invalid? Wrong comments? Yes, the obvious div you quoted
is a typo. Maybe even the reason it didn't work. But all the rest of
the comments correctly identify the div they are ending. A very
important coding convention if you want any hope of dealing with
"spaghetti HTML" generated by someone else's "spaghetti PHP"

Why don't you therefore correct this now. How about a url with
your best shot (after you have answered above query).

Don't get upset. I did not mean to offend you (perhaps I was not
liking having to stay in Sunday yesterday to meet a Monday
deadline <g>)

--
dorayme

dorayme wrote:

So? Why does this preclude you using a table for selected data in
a separate file considering it looks rather like tabular data you

It doesn't. But I'd still like to understand the CSS & div issue.

are dealing with? I recall there being a relationship between the
cells, perhaps you might argue it is not really tabular in spite
of the appearance?

If you look at http://UniGen.us/PGV/FGS?famid=F25&ged=wgroleau
compared to [1] http://UniGen.us/PGV/FGS-div?famid=F25&ged=wgroleau
you will see how the parents and grandparents were arranged in
the old version. If you view source, you will see, though
"spaghetti" might be hyperbole, why I want to simplify this thing.

Of course you won't be able to see how complicated the PHP is
unless you download it from www.phpgedview.net
The original version is
http://UniGen.us/PGV/family?famid=F25&ged=wgroleau

Although a case could be made that it is tabular, the original
(and many other parts of the code) uses much more complicated
tables to produce layouts that are not tabular (e.g., the pedigree
tree). I want to figure out ways to simpify it that will still
allow using non-tabular formats without excessive tables.

Don't get upset. I did not mean to offend you (perhaps I was not
liking having to stay in Sunday yesterday to meet a Monday
deadline <g>)

Forgiven. I understand that situation!

[1] Apologies that I have been working on the table version,
so the two are probably not completely equivalent.

--
Wes Groleau

Change is inevitable.
Conservatives should learn that "inevitable" is not a synonym for "bad."
Liberals need to learn that "inevitable" is not a synonym for "good."
-- WWG

In article <5l0lj.1947$hk4.553@trnddc03>,
Wes Groleau <groleau+news (AT) freeshell (DOT) org> wrote:

dorayme wrote:
So? Why does this preclude you using a table for selected data in
a separate file considering it looks rather like tabular data you

It doesn't. But I'd still like to understand the CSS & div issue.

are dealing with? I recall there being a relationship between the
cells, perhaps you might argue it is not really tabular in spite
of the appearance?

If you look at http://UniGen.us/PGV/FGS?famid=F25&ged=wgroleau
compared to [1] http://UniGen.us/PGV/FGS-div?famid=F25&ged=wgroleau
you will see how the parents and grandparents were arranged in
the old version. If you view source, you will see, though
"spaghetti" might be hyperbole, why I want to simplify this thing.

Of course you won't be able to see how complicated the PHP is
unless you download it from www.phpgedview.net
The original version is
http://UniGen.us/PGV/family?famid=F25&ged=wgroleau

Although a case could be made that it is tabular, the original
(and many other parts of the code) uses much more complicated
tables to produce layouts that are not tabular (e.g., the pedigree
tree). I want to figure out ways to simpify it that will still
allow using non-tabular formats without excessive tables.

OK I had a quick look at the two urls you mention above and they
so little separate content from style that I had trouble getting
to the heart of the issue that concerns you. I will try to find
your original post later but may I make a suggestion:

Take some bit that is presently laid out with tables, that is not
obviously tabular data in itself, and post a url to it and it
alone (ie. make a test case). And then ask how it could be done
without tables. I can assure you, you will get plenty of help
then. But lets be clear about this:

In a big table (that should be a table) the contents of the cells
are not necessarily further tables. For example, I might have a
table of item names, colours, and prices. The colours (or the
prices) are not material for further tables. They are likely
lists or simple comma separated text material inside the cells.

In a way, it really is a simple matter. Do not even try to do
without tables where tables are the right tool for the job. They
are the right tool whenever there is tabular relationships
needing to be exhibited. If you try to do without them because
you think you will simplify something, you will probably fail on
the whole. But on the other hand, if you are able to identify
material which in itself (either the content of cells or not) is
not tabular in nature, then there are generally good solutions
for laying *this* bit out without tables.

--
dorayme

dorayme wrote:

OK I had a quick look at the two urls you mention above and they
so little separate content from style that I had trouble getting
to the heart of the issue that concerns you. I will try to find

That IS the issue that concerns me! :-)

Take some bit that is presently laid out with tables, that is not
obviously tabular data in itself, and post a url to it and it

I did:

The original version is
http://UniGen.us/PGV/family?famid=F25&ged=wgroleau

alone (ie. make a test case). And then ask how it could be done
without tables. I can assure you, you will get plenty of help

But I don't want to do _that_ without tables.
I don't want to do that at all.

In a big table (that should be a table) the contents of the cells
are not necessarily further tables. For example, I might have a

Of course. But I am trying to clean up a messy house, one room
at a time, while living in it. I don't have the luxury of
burning it down and building a new one.

In a way, it really is a simple matter. Do not even try to do
without tables where tables are the right tool for the job. They
are the right tool whenever there is tabular relationships
needing to be exhibited. If you try to do without them because
you think you will simplify something, you will probably fail on

What I said was, I'd like to to do an arrangement of these people
without tables for two reasons:

1. To learn how to do it where I can see the "big picture" in
a few dozen lines, rather than the much more complicated
subroutines that I'll tackle later.

2. Because, although my arrangement looks tabular--and it could
be argued that it _is_ tabular--the original arrangement
of the same boxes, the family "tree," is just as logical,
and I would like to allow people to switch to that with
as much work as possible in the CSS, not in the code.

--
Wes Groleau

He that is good for making excuses, is seldom good for anything else.
-- Benjamin Franklin

Wes Groleau wrote:

dorayme wrote:
OK I had a quick look at the two urls you mention above and they so
little separate content from style that I had trouble getting to the
heart of the issue that concerns you. I will try to find

That IS the issue that concerns me! :-)

Take some bit that is presently laid out with tables, that is not
obviously tabular data in itself, and post a url to it and it

I did:

The original version is
http://UniGen.us/PGV/family?famid=F25&ged=wgroleau

Yowza!

Lets go back to the original request:


+-----+-----+-----+-----+

PGF | PGM | MGF | MGM |
+-----+-----+-----+-----+
father | mother |
+-----------+-----------+
child |
+-----------------------+
child |
+-----------------------+

Short lesson in float: left;


And just take the top row.

<div class="row">
<div class="GF_GM">PGF</div>
<div class="GF_GM">PGM</div>
<div class="GF_GM">MGF</div>
<div class="GF_GM">MGM</div>
<div style="clear: both">use this div to give the row height, if you
need it, other tricks available</div>
</div>

styles would look like;

..row{clear: both} /* keeps "rows" from stacking wrong */

..GF_GM{
float: left;
width: 20%;
border: 1px dotted black;
height: 120px;
margin: some value if you want it;
padding: 2em;
}

In your case I would probably keep the tabular data inside the boxes
in tables, as they are.

Problems you will have:

Height! You will probably want all the "boxes" to be the same
height. You can either let the content determine the height, specify a
height or use a bit of javascript to add bottom padding to make them all
the same height.

Jeff

alone (ie. make a test case). And then ask how it could be done
without tables. I can assure you, you will get plenty of help

But I don't want to do _that_ without tables.
I don't want to do that at all.

In a big table (that should be a table) the contents of the cells are
not necessarily further tables. For example, I might have a

Of course. But I am trying to clean up a messy house, one room
at a time, while living in it. I don't have the luxury of
burning it down and building a new one.

In a way, it really is a simple matter. Do not even try to do without
tables where tables are the right tool for the job. They are the right
tool whenever there is tabular relationships needing to be exhibited.
If you try to do without them because you think you will simplify
something, you will probably fail on

What I said was, I'd like to to do an arrangement of these people
without tables for two reasons:

1. To learn how to do it where I can see the "big picture" in
a few dozen lines, rather than the much more complicated
subroutines that I'll tackle later.

2. Because, although my arrangement looks tabular--and it could
be argued that it _is_ tabular--the original arrangement
of the same boxes, the family "tree," is just as logical,
and I would like to allow people to switch to that with
as much work as possible in the CSS, not in the code.

Jeff wrote:

Lets go back to the original request:

+-----+-----+-----+-----+
| PGF | PGM | MGF | MGM |
+-----+-----+-----+-----+
| father | mother |
+-------- [snip] -------+

Short lesson in float: left;

And just take the top row.

div class="row"
div class="GF_GM">PGF</div
div class="GF_GM">PGM</div
div class="GF_GM">MGF</div
div class="GF_GM">MGM</div
div style="clear: both">use this div to give the row height, if you
need it, other tricks available</div
/div

styles would look like;

.row{clear: both} /* keeps "rows" from stacking wrong */

.GF_GM{
float: left;

I'll give that a try. I tried putting a float left and a float right in
a another div twice and then floating those left and right.

But I got all four on the left margin stacked vertically

Height! You will probably want all the "boxes" to be the same height.

At present the content is generated elsewhere with fixed height.

--
Wes Groleau

Change is inevitable. We need to learn that "inevitable" is
neither a synonym for "good" nor for "bad."
-- WWG