urosm
/
ikiwiki
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

respond

master
smcv 2019-02-03 14:39:51 -04:00 committed by admin
parent d9a018160f
commit 5ffe09e616
1 changed files with 30 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

30
doc/todo/support_multi-row_table_headers.mdwn
View File

@ -96,3 +96,33 @@ and easily underneath.
I'd appreciate your take on the above suggestions [[smcv]] before I roll my sleeves up.
Thanks! — [[Jon]] (2018-09-24)
> I continue to think that the `header` parameter shouldn't be sometimes a
> description of which parts of the table are header, and sometimes the header
> data itself; so if you want an inline header, it should indeed have a
> distinct name.
>
> If you can think of a good name for the new parameter, and can document it
> reasonably clearly, then I would be OK with having a separate parameter that
> is the externally-provided header. I don't know what the right name for that
> parameter would be: `headercontent` or `headerblock` is unwieldy but I can't
> think of anything better.
>
> It would maybe simplify things to make it mutually exclusive with `header`,
> but then you wouldn't be able to express things like "the first column of my
> CSV is a header, the first row is just an ordinary row, and please add
> this literal header row to the top".
>
> It might help to write the documentation and/or tests first, and then
> implement it afterwards, when you have an "API" you're happy with.
>
> Corner cases:
>
> How would it work if you want to add a literal header column on the left
> rather than adding a literal header row on the top? If you add both, what
> happens at the top left corner?
>
> Is it necessary to be able to add header columns on the right (for RTL
> languages?), or header rows (footer rows, I suppose) on the bottom?
>
> --[[smcv]]