Re: HTML Output for @table and @multitable

[Patrice Dumas]

Hello,

A disclaimer, I don't know CSS at all, so I may be misunderstanding many
issues.


On Sun, Nov 23, 2014 at 06:51:41AM +0800, Mahlon wrote:
> Hi Gavin,
> 
> I agree that the HTML is straightforward, but here are my specific concerns.
> 
> 1) In the info output, there is an 'underline' after the header
> line, but no underline in HTML.

That's not really an issue.  In Info there is no possibility of bold nor
change in font size, so the underline is the only way to mark a header,
but in HTML and TeX, there are other ways, in my opinion better ways to
mark a header.  The formatting need not be exactly the same, what is
important is that reader connect the 2 formatting, and do not see
different logical organization when looking at HTML, Info or pdf output.

> 2) HTML compresses whitespace, so line-item columns appear much
> closer together than in the info output. Unfortunately it is _only_
> the line items that are compressed. The header line retains the
> original spacing which throws off the column alignment between
> header and line items.

I don't get it at all...

> 3) Spacing between lines specified in the source does not carry over
> to the HTML, even if we insert a '@sp 1' into the source. 

Normally, @sp 1 becomes one <br>, so it should appear?

> Some
> tables in the source will specify line spacing and some will not. In
> the HTML, there is _always_an extra line in the <dl> sequence and
> _never_an extra line in the <table> sequence. Unfortunately, a
> post-processor has no way of knowing what the source intended
> because there is no clue in the HTML output.

I don't get it.  Why is there always an extra line in the <dl> sequence?
And why never in the <table> sequence?  We use rather simple HTML markup 
as intended, maybe with some styling, but, in most case it is just plain
HTML markup.

> All of this (except the clairvoyance) is cleanly handled by the
> provided CSS, and perhaps it's too much work to handle it with
> generated definitions. Still, someone may eventually get a brilliant
> idea about how to generate tables that don't need post-processing.

Post-processing for what?


In any case, there is something that is certainly sub-optimal, it is the
@itemize with anything else than @bullet, as we remove the bullet from
<li> and then add a symbol in the text.  I have no idea how to do
something better, though, opinions welcome.

-- 
Pat