Descendant chart rendered in CSS

[Haines Brown]

Genealogists often display their data as an ascending or descending
chart, and for presentation on the web usually prepare a PDF file or
HTML table. I was interested in a pure CSS solution without using a
table.

So I did a prototype:

www.hartford-hwp.com/genealogy/test.html

Does anyone have suggestions either about how it could be improved or
other approaches that would be preferable to CSS without a table?

--

Haines Brown, KB1GRM

[dorayme]

In article <87************@teufel.hartford-hwp.com>,
Haines Brown <br****@teufel.hartford-hwp.comwrote:

Genealogists often display their data as an ascending or descending
chart, and for presentation on the web usually prepare a PDF file or
HTML table. I was interested in a pure CSS solution without using a
table.

So I did a prototype:

www.hartford-hwp.com/genealogy/test.html

Does anyone have suggestions either about how it could be improved or
other approaches that would be preferable to CSS without a table?

There are some end tags for span missing.

Any special reason to use XHTML 1.0 Strict rather than 4.01
Strict?

--
dorayme

[Haines Brown]

dorayme <do************@optusnet.com.auwrites:

There are some end tags for span missing.

Ouch. Fixed, and this time validated. Thanks.

Any special reason to use XHTML 1.0 Strict rather than 4.01
Strict?

An old debate. I suppose the reason is that I've got some 15,000
documents on line, and there's no way in the world I'll ever be able
to go back and update them.

Not many people use CSS without tables for report charts, and I'm not
sure why. From what I've seen tables does not really make things any
simpler.

--

Haines Brown, KB1GRM

[dorayme]

In article <87************@teufel.hartford-hwp.com>,
Haines Brown <br****@teufel.hartford-hwp.comwrote:

dorayme <do************@optusnet.com.auwrites:

There are some end tags for span missing.

Ouch. Fixed, and this time validated. Thanks.

Any special reason to use XHTML 1.0 Strict rather than 4.01
Strict?

An old debate. I suppose the reason is that I've got some 15,000
documents on line, and there's no way in the world I'll ever be able
to go back and update them.

Not many people use CSS without tables for report charts, and I'm not
sure why. From what I've seen tables does not really make things any
simpler.

I was sort of impressed but have not studied your code properly.
I will, out of interest if not more, when I have time as I am
soon to make a website for a "historical society" which will be
using such charts from time to time among other things).

A data tree is a "tabular" informational structure and so, a
table would seem, prima facie, to be the semantically appropriate
construct. I hope you did what you did because you were exploring
a way to make a tree in a simpler way and not just to avoid
tables <g>

As for "updating" to an earlier doctype, pity the doctypes were
not in an "include" so you could change just one file.

--
dorayme

[Haines Brown]

dorayme <do************@optusnet.com.auwrites:

A data tree is a "tabular" informational structure and so, a table
would seem, prima facie, to be the semantically appropriate
construct. I hope you did what you did because you were exploring a
way to make a tree in a simpler way and not just to avoid tables <g>

I've not yet made up my mind on the first issue. It is an interesting
question, but not all that important in my mind. The thing about a
genealogical chart is that it not only contains some data about
individuals, but more importantly it displays their relationships.

A table also displays relationships, but of a different sort, and
generally organizes data in terms of general categories. If the rows
in a table represent months, the data in that row are instances within
that time frame. In contrast, the relationships in a genealogical
chart are unique, such as person B being the child of person
A. Furthermore, I suspect it is a fact that genealogists actually do
use tables for _layout_ rather than simply expose the relationships of
data, and that's a no-no.

However, if a table seems better, I wouldn't object to it. What are
these criteria of "betterness"? One would be a pleasing visual effect
over which one has extensive control. Another might be how easily data
can be added or subtracted from the whole by means of a script. If
someone prefers not to develop or purchase software for handling data
in this way, then markup should be relatively simple and transparent
so that adjustments can be made with minimal time and effort.

My aim was to explore pure CSS vs. CSS with table in terms of such
criteria by actually trying to develop a descendant chart without a
table. I had no idea it was not a common practice. One thing, though:
pure CSS seems to me to be more fun - more of an interesting challenge.

I was sort of impressed but have not studied your code properly.

"Impressed" in what sense? That it could be done at all? ;-) I only
found two examples of people exploring this path, which rather
surprised me.

As for "updating" to an earlier doctype, pity the doctypes were not
in an "include" so you could change just one file.

The problem here is that with the change of doctype, standards also
change. What would be valid markup years ago certainly wouldn't pass
muster now. For example, it was once conventional to make the element
<HRupper case, but today it would have to be <hr />. XML might not
be the juggurnaut it was once thought, but it seems inevitable.

--

Haines Brown, KB1GRM

[Andy Dingley]

On 11 Mar, 22:37, dorayme <[e-mail]:

Any special reason to use XHTML 1.0 Strict rather than 4.01
Strict?

The only genealogy I've ever fooled about with on the web used
embedded SVG too. XHTML (as XML) was useful here.

I really like the OP's original example.

I'm not so sure about the <ulinside the boxes though. This is a set
of properties, not a list (although that's not a clear distinction in
HTML). Each property certainly needs a class attahced to it. I'd also
favour losing the <ul/ <limarkup in favour of a simple <divfor
each.

[Haines Brown]

"Andy Dingley" <di*****@codesmiths.comwrites:

Each property certainly needs a class attahced to it. I'd also
favour losing the <ul/ <limarkup in favour of a simple <divfor
each.

Andy, would you mind expanding on your comment? I don't see why
"properties" (in this case, a person's dates, marriage status, place
of residence) are best put into a div rather than, say, merely a set
of lines ending in <br />. While using a div would be one way to put
each property line into its own class, I'm not sure that is what you
are recommending, and if so why.

--

Haines Brown, KB1GRM

[Bergamot]

dorayme wrote:

>
A data tree is a "tabular" informational structure and so, a
table would seem, prima facie, to be the semantically appropriate
construct.

I disagree. A data tree is more a multi-level list than a table.

--
Berg

[Andy Dingley]

On 12 Mar, 00:04, dorayme <[e-mail]:

A data tree is a "tabular" informational structure

It isn't. "Tabular" in this local sense means two-dimensional. A tree
is of fractal dimension between 1 and 2 (possibly greater than 2 for
some representations of genealogy).

[Andy Dingley]

On 12 Mar, 13:14, Haines Brown <[e-mail]:

"Andy Dingley" <[e-mail]:

Each property certainly needs a class attahced to it. I'd also
favour losing the <ul/ <limarkup in favour of a simple <divfor
each.

Andy, would you mind expanding on your comment?

Your nodes are coded something like this:

<div class="node">
<div class="line-lower"></div>

<div class="person">
John Gilbert Brown
<ul>
<li>(1881 to 1882)</li>
<li>Not married</li>
<li>Camden, NJ</li>
</ul>
</div>
</div>
As a first refactoring, I'd change to this:

<div class="node person" >

<div class="line-lower"></div>

<div class="full-name" >John Gilbert Brown</div>
<div class="dates" >(1881 to 1882)</div>
<div class="marital-status" >Not married</div>
<div class="location" >Camden, NJ</div>
</div>

Each nested <divrepresents a "property" of a node that is of person-
type.

With trivial CSS, I can make it look identical to the default list
presentation. With more work, I can make it look a lot more
sophisticated in ways that I couldn't for the list markup.

Note that I've also simplified the content model here, in that "name"
is now a property like "dates", rather than merely being the outermost
text part of the node's mixed content model (such a structure is a
pain to process).

I'm also approaching this from an RDF and Semantic Web background. I'd
personally put _much_ more annotation onto this structure, such that
it was also a useful machine-processable document, not just a good
HTML document for human-readbale presentation. That's also a lever
towards using XML.

I might even move the "connector's" class onto the node <div>, rather
than as a nested <div>. This might then be harder to render though, so
maybe not.

In fact I'd sub-divide the property structures even further. I'd use
vCard to structure the name (especially making the surname accessible
to simple CSS). I'd have all the dates, and their meanings, machine-
visible (births, deaths, marriages). I'd probably use a list structure
for partnerings, even for single marriages in a lifetime (this is
easier to process with XML tools, even though RDF/XML would allow me
to have a single-valued ot list-valued resource for the "partners"
property).

I would not try to "minimise" the markup in any way. Verbose and
simple beats complicated and terse, IMHO.

I might even see if there was an existing RDF schema such as FOAF
(maybe even a genealogy schema) that I could incorporate.

I don't see why
"properties" (in this case, a person's dates, marriage status, place
of residence) are best put into a div rather than, say, merely a set
of lines ending in <br />.

A list of <liis fine, so long as each distinct property has a
distinct class (how else would you highlight the dates alone by CSS?)

The use of <brwould be a _bad_ idea. <bris an inline element, not
a structural one. Its meaning is no more than a semi-presentational
linebreak, not any real semantic scope. It's harder to manipulate
mixed-content model XML ("data, separator, data" structures) than it
is to work with containment-structured XML, such as "<a>...</a><b>...</
b>".

[Nick Theodorakis]

On Mar 11, 2:58 pm, Haines Brown <[e-mail]>
wrote:

Genealogists often display their data as an ascending or descending
chart, and for presentation on the web usually prepare a PDF file or
HTML table. I was interested in a pure CSS solution without using a
table.

So I did a prototype:

www.hartford-hwp.com/genealogy/test.html

Does anyone have suggestions either about how it could be improved or
other approaches that would be preferable to CSS without a table?

I once had a try at rendering family descendants using nested list
elements to show relationships:

<http://theodorakis.net/elvishgenealogy.html>

It was an experimental page, and I sort of lost interest in the
experiment, but there it is if you want to use any ideas from it.

Nick

--
Nick Theodorakis
ni**************@hotmail.com
contact form:
http://theodorakis.net/contact.html

[Haines Brown]

Andy,

Thanks for the raft of stimulating suggestions.

"Andy Dingley" <di*****@codesmiths.comwrites:

Each nested <divrepresents a "property" of a node that is of
person- type.

With trivial CSS, I can make it look identical to the default list
presentation. With more work, I can make it look a lot more
sophisticated in ways that I couldn't for the list markup.

That's easy to do, and the idea of imposing the logical structure is
intellectually appealing. But can you give me an example of how the
appearance might be more sophisticated?

I'm also approaching this from an RDF and Semantic Web
background. I'd personally put _much_ more annotation onto this
structure, such that it was also a useful machine-processable
document, not just a good HTML document for human-readbale
presentation. That's also a lever towards using XML.

Again, very interesting. It goes beyond the purpose of my initial
little prototype chart, but I think I'll pursue it a bit more in that
direction.

I might even move the "connector's" class onto the node <div>,
rather than as a nested <div>. This might then be harder to render
though, so maybe not.

I nested the connector divs mainly to keep alignment problems to a
minimum. I suppose this is what you mean:

<div class="generation">
<div class="horiz-connector">
<div class="node">
<div class="personal_name">...
<div class= ...
</div>
<div class="vert-connector">
</div>

However, it is still not logical in that the "horiz-connector" is
cross-generational. The following strikes me as logical:

<div class="generation">
...
</div<!-- close first generation -->
<div class="horiz-line"></div>
<div class="generation">
<div class="vert-line">
<div class="node">
...
</div>
<div class="node">
</div>
</div<!-- close vert-line -->
</div<!-- close second generation -->

Sorry to go on like this, but you got me started ;-) The logic here is
that people are a specification of sibling relationships, while a
horizontal line is a generational relationship.

In fact I'd sub-divide the property structures even further. I'd use
vCard to structure the name (especially making the surname accessible
to simple CSS).

That would never have occurred to me, but I'll explore the idea.

I might even see if there was an existing RDF schema such as FOAF
(maybe even a genealogy schema) that I could incorporate.

Here is an example of the application of OWL (Web Ontology Language)
to genealogy:

http://www.nucleartoiletpaper.com/genesis/dm-intro.htm

There is much on line for RDF/OWL in genealogy.

A list of <liis fine, so long as each distinct property has a
distinct class (how else would you highlight the dates alone by CSS?)

The use of <brwould be a _bad_ idea. <bris an inline element, not
a structural one. Its meaning is no more than a semi-presentational
linebreak, not any real semantic scope. It's harder to manipulate
mixed-content model XML ("data, separator, data" structures) than it
is to work with containment-structured XML, such as "<a>...</a><b>...</
b>".

Yes. Thanks for sharing your wisdom. Some ideas may be a bit ambitious
for me (lack of time), but I suspect I'll try to implement some of the
logical structure stuff.

--

Haines Brown, KB1GRM

[Haines Brown]

Nick, thanks to the pointer to an interesting approach (names in a UL
list with LI markers being a graphic of a right angle). It makes for a
nice clean markup, but seems to depend on presumptions that are
dissimilar to the usual generalogy chart.

--

Haines Brown, KB1GRM

[dorayme]

In article <55*************@mid.individual.net>,
Bergamot <be******@visi.comwrote:

dorayme wrote:

A data tree is a "tabular" informational structure and so, a
table would seem, prima facie, to be the semantically appropriate
construct.

I disagree. A data tree is more a multi-level list than a table.

I did say "prima facie" - I was beginning to wonder myself
actually!

OP said, poignantly enough, at one stage, "the relationships in a
genealogical chart are unique, such as person B being the child
of person A." and "Furthermore, I suspect it is a fact that
genealogists actually do use tables for _layout_ rather than
simply expose the relationships of data, and that's a no-no."

I suspect he is right about the latter. As for the former, the
matter is not quite as simple. At least it does not preclude the
idea of tabular data applying to these descendant relationships.
Remember, while the relationship of a particular parent to a
child is unique enough in one sense, it is still the same kind of
relationship that other parents have to their children. In a very
abstract sense, I sense that this is tabular material.

About multilevel lists and such charts. Fine, but they are very
ordered too. Order is at the heart of them. And you might know I
think that I think ordered lists are at bottom tabular in nature.

What you and OP and AD are saying is likely a better practical
way to think about things. It is perhaps awkward practically to
come up with a table or tables within tables (that is not just
for layout) to represent the order required. But I will think
about it!

--
dorayme

[Andy Dingley]

On 12 Mar, 20:11, Haines Brown <[e-mail]:

That's easy to do, and the idea of imposing the logical structure is
intellectually appealing. But can you give me an example of how the
appearance might be more sophisticated?

The obvious ones would be as simple as applying CSS and bold fonts to
a property like the birth dates rather than the deaths, or (if you use
vCard too) to the surname rather than the whole name.

I might even move the "connector's" class onto the node <div>,
rather than as a nested <div>. This might then be harder to render
though, so maybe not.

I nested the connector divs mainly to keep alignment problems to a
minimum. I suppose this is what you mean:

<div class="generation">
<div class="horiz-connector">
<div class="node">
<div class="personal_name">...
<div class= ...
</div>
<div class="vert-connector">
</div>

Not really. I was looking at the structure inside "node", such as the
person's information and the connector. I haven't looked in detail at
just how you make the connectors appear, or at how you mark-up nodes
"within" generations. After all, "generation" doesn't really exist and
it can be problematic to assume it does, if distant cousins start
marrying between generations (I live near Wiltshire).

My thought was whether you really needed a <divfor the "connector"
insode the "node", or if you could manage by simply adding the class
to the node itself's <div>.

http://www.nucleartoiletpaper.com/genesis/dm-intro.htm

There is much on line for RDF/OWL in genealogy.

You might enjoy fiddling with Protege and Jambalaya then.

Given the complexity of this application, I'd want to be using RDF/OWL
to represent it, not paltry XML or even HTML