10:45
<mpt>
jgraham, a genealogical table is something HTML happens not to have semantics for, I think
10:45
<mpt>
At least, it doesn't make *semantic* sense to have to change the rowspan of every cell in the table whenever you add a generation, but that's what <table> requires
10:48
<mpt>
A genealogical table has the same semantics as a cladistic tree (e.g. <http://www.gingersrus.com/CostaceaeCladistics.gif>;), but the latter happens not to have a tabular layout
10:55
<mpt>
And once you've started trying to mark up the semantics of purely-hierarchical trees, you're just one line away from not-purely-hierarchical trees such as <http://www.lyricsvault.net/history/MusicGenealogy.jpg>; and <http://www.levenez.com/unix/history.html>;
10:57
<othermaciej>
so what markup would be appropriate for a general directed graph?
10:59
<othermaciej>
it seems like marking such a thing up in a purely semantic way and yet still getting the desired presentation is a rather difficult problem
11:18
<mpt>
Isn't that what RDF was supposed to be for?
11:18
mpt
ducks
11:19
jgraham
is worried he was thinking exactly the same thing at the same moment
11:19
<jgraham>
But it doesn't solve the presentation problem, of course
11:20
<mpt>
XSLT into SVG?
11:20
mpt
is spewing random acronyms at this point, and should probably be ignored
11:21
<mpt>
It's not as if browser layout engines have the smarts to lay out trees like that anyway
11:22
<mpt>
Implementing it would be like implementing tables from scratch, squared
11:22
<jgraham>
But you still need to be able to get at the underlying data somehow. Maybe if you throw a little XBL into the mix you can bind the svg representation to the underlying data
11:22
<mpt>
(because for example one branch of the family might be pushed lower so as to accommodate the width of another branch higher up)
11:23
<jgraham>
but I may be misremembering what XBL is capable of
11:24
<othermaciej>
I'm not sure if XBL has sufficient powers to transform the DOM to dynamically convert RDF to SVG in a way that visually represents the graph
11:25
<othermaciej>
I guess XBL can always fall back to JS but I am not sure how much JS can manipulate the contents of the shadow tree
11:25
<othermaciej>
XSLT would only be suitable for static applications
11:28
<Philip`>
Semantics for its own sake doesn't seem useful - it's useful when it enables things like media independence, but media independence seems infeasible here since a standard visual family tree and a small-screen version and an aural version will have to be completely different presentations and each carefully designed to be understandable
11:28
<othermaciej>
I think datagrid can provide the semantics for things that are truly a tree but would require major styling heroics to get the presentation right
11:29
<othermaciej>
if you had a family tree *editor* though, you'd definitely want to be able to edit an underlying data model and have the presentation reflect that
11:29
<Philip`>
(http://www.pointerklubben.se/stamtavla.asp?Id=S35236/97 in Opera's Small Screen mode silently loses most of the page's information)
11:32
<jgraham>
I wonder how successful existing desktop family tree editors are at being accessible. I would guess "not very"
11:32
<mpt>
The standard interchange format for genealogical info is called Gedcom
11:33
<mpt>
I think it predates XML in the same way as MathML does
11:33
<mpt>
http://en.wikipedia.org/wiki/GEDCOM
11:35
mpt
remembers trying to implement a Gedcom parser as a CS project
11:58
zcorpan
added <datatemplate>, <rule condition mode>, <nest filter mode> to html5-elements
12:01
zcorpan
now also added ref, registrationmark and template to the global attributes
12:10
<jgraham>
http://james.html5.org/temp/html5lib-0.10.zip
12:10
<jgraham>
Pre-release for testing
12:38
<Lachy>
I upgraded the blog to Wordpress 2.3
17:53
<jgraham>
bzed: re: setuptools; I think it still makes sense for people who are not running Debian. It's not as simple or reliable as I would like but nevertheless has some nice features.
18:23
<bzed>
jgraham: we had a long discussion with the fedora people about setuptools and co some time ago, I think all agreed that setuptools is broken by design and seems to have an upstream which does not react on the wishes of users and the distributions
19:43
<bzed>
jgraham: and even from a user's point of view - I too often had completely random problems with setuptools, switching to distutils fixed that easily.
22:41
<Philip`>
<header><span> ...non-inline content... </span></header> seems to be useful for making Firefox parse correctly, but I expect it's annoyingly nonconforming :-(
22:47
<zcorpan>
hsivonen: your html4 parser should perhaps know about boolean attributes and set appropriate values when they appear as minimized
22:48
<zcorpan>
hsivonen: see the last error in http://validator.nu/?doc=http%3A%2F%2Fwww.apple.com%2F
22:50
<jgraham>
Philip`: Yeah. Annoyingly, the relevant bug is marked blocking 1.9- and I'm not clever enough to work out how to make unknown elements work with the Mozilla residual style thing
22:50
<jgraham>
Bug relevant to making unknown elements able to contain blocks, that is
23:02
Philip`
decides to do <header><span> and treat conformance as a guideline rather than a rule
23:03
<Philip`>
(I just hope it doesn't make things break confusingly in certain cases)
23:04
<zcorpan>
Philip`: why not <div class=header>?
23:08
<jgraham>
zcorpan: Well potentially he wants to make use of the header algorithm
23:11
<Philip`>
So that my site will work (or, at least, break more interestingly) when UAs start supporting HTML5 features
23:23
<zcorpan>
hsivonen: <iframe> isn't a cdata element according to html4 (see message 4 in http://validator.nu/?doc=http%3A%2F%2Fwww.blogger.com )
23:33
<zcorpan>
(neither are title or textarea rcdata elements according to html4)