X-Git-Url: http://git.vanrenterghem.biz/git.ikiwiki.info.git/blobdiff_plain/534797d71997be4f37bf4946e7e8c351ea0d9706..3c9537af5df0affc2c9ecd8dc4250f2ef07f401d:/doc/todo/support_multi-row_table_headers.mdwn diff --git a/doc/todo/support_multi-row_table_headers.mdwn b/doc/todo/support_multi-row_table_headers.mdwn index 2b22d5d3e..6f13bbb23 100644 --- a/doc/todo/support_multi-row_table_headers.mdwn +++ b/doc/todo/support_multi-row_table_headers.mdwn @@ -13,7 +13,13 @@ It would be great if it were possible to support multi-row table headers in the [[!tag wishlist patch]] > This seems like weird overloading of the header parameter - it's -> table data, except when it isn't. Perhaps +> table data, except when it isn't. + +> > My first cut (now rebased out of existence I think) introduced a +> > new "headerblock" parameter, but trying to clearly document the +> > interaction of data/headerblock/header parameters was too awkward. -- [[Jon]] + +> Perhaps > something like this would be easier to use in practice? > (and also more featureful :-) ) > @@ -23,7 +29,17 @@ It would be great if it were possible to support multi-row table headers in the > ikiwiki | no | yes | yes > Starcraft | yes | yes | via Wine > """]] -> + +> > Thanks for your prompt feedback! +> > +> > This would probably be good, yes, and having mixed row/column headers is +> > definitely a nice-to-have. I don't relish the prospect of writing the parser +> > but I see you've made a stab already... +> > +> > One thing you'd lose, but it's debatable whether this is valuable, would be +> > to have the header defined in the directive, and the remaining table data +> > declared in an external CSV. -- [[Jon]] + > intended to be rendered like > > @@ -56,3 +72,8 @@ It would be great if it were possible to support multi-row table headers in the > `header="1 row, first 2 cols, last column"`. > > --[[smcv]] + +> > To be clear I think your suggestion is a good one, but my hack has +> > addressed my immediate need so it's the one I'm deploying at $ork for the +> > time being. I'm unlikely to have time to implement this solution in the +> > near future. -- [[Jon]]