| 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) |