From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from scc-mailout-kit-01.scc.kit.edu (scc-mailout-kit-01.scc.kit.edu [129.13.231.81]) by fantadrom.bsd.lv (OpenSMTPD) with ESMTP id 1cbe0117 for ; Sat, 1 Dec 2018 12:21:01 -0500 (EST) Received: from asta-nat.asta.uni-karlsruhe.de ([172.22.63.82] helo=hekate.usta.de) by scc-mailout-kit-01.scc.kit.edu with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (envelope-from ) id 1gT8ws-00058I-Vr; Sat, 01 Dec 2018 18:21:00 +0100 Received: from donnerwolke.usta.de ([172.24.96.3]) by hekate.usta.de with esmtp (Exim 4.77) (envelope-from ) id 1gT8wr-0004RT-Ar; Sat, 01 Dec 2018 18:20:57 +0100 Received: from athene.usta.de ([172.24.96.10]) by donnerwolke.usta.de with esmtp (Exim 4.84_2) (envelope-from ) id 1gT8wr-00076s-6N; Sat, 01 Dec 2018 18:20:57 +0100 Received: from localhost (athene.usta.de [local]) by athene.usta.de (OpenSMTPD) with ESMTPA id 1eeee358; Sat, 1 Dec 2018 18:20:57 +0100 (CET) Date: Sat, 1 Dec 2018 18:20:57 +0100 From: Ingo Schwarze To: Pali Rohar Cc: discuss@mandoc.bsd.lv Subject: Re: Broken tables in HTML output Message-ID: <20181201172057.GD89021@athene.usta.de> References: <20180716110335.uusqzhscwdgp5qaa@pali> <20180716152919.GB85992@athene.usta.de> <20181126212728.GG82448@athene.usta.de> <20181126215826.xepdfaas5fm42ubc@pali> <20181126220133.bf7siow6e5mxahhv@pali> <20181126220516.nrflslyvxufb7xnk@pali> X-Mailinglist: mandoc-discuss Reply-To: discuss@mandoc.bsd.lv MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20181126220516.nrflslyvxufb7xnk@pali> User-Agent: Mutt/1.8.0 (2017-02-23) Hi Pali, Pali Rohar wrote on Mon, Nov 26, 2018 at 11:05:16PM +0100: > On Monday 26 November 2018 23:01:33 Pali Rohar wrote: >> On Monday 26 November 2018 22:58:26 Pali Rohar wrote: >>> I tested new cvs changes for following table: >>> .TS >>> box; >>> c|c|c. >>> A A1 A_ >>> \^ A2 \^ >>> _ >>> B B1 B_ >>> _ >>> C C1 C_ >>> \^ C2 \^ >>> _ >>> E E1 E_ >>> \^ E2 \^ >>> \^ E3 \^ >>> _ >>> F F1 F_ >>> .TE The table syntax looks sane to me. >>> And in chromium browser 70 there is missing horizontal line between >>> A and B; and also between C and D. See attachment how it looks like. >>> >>> It is really suspicious that horizontal line is just between A2 and B1. >>> And not across whole line. The rendering in the PNG file you attached seems broken in multiple respects: * The outer border of the table as a whole is rendered as "double", even though the mandoc HTML output clearly says: * Same for the horizontal line between B and C: * Same for the horizontal line between A and B: So whatever produced that PNG file seems quite broken. Oh, one among the bugs in that software could be that for deciding where to draw the borders of a row, it only looks at the element itself. On https://www.w3.org/TR/html/tabular-data.html the algorithm for processing rows says in step 13: Let the slots with coordinates (x, y) such that xcurrent <= x < xcurrent+colspan and ycurrent <= y < ycurrent+rowspan be covered by a new cell c, anchored at (xcurrent, ycurrent), which has width colspan and height rowspan, corresponding to the current cell element. That implies that all slots in the second row of the table - the row that contains A2 - are covered. The first slot is covered by the cell A, the third slot by the cell A_. And right below "4.9.12. Processing model" it says: A row is a complete set of slots from x=0 to x=xwidth-1, for a particular value of y. And https://www.w3.org/TR/CSS2/tables.html says below "17.6.2 The collapsing border model": In the collapsing border model, it is possible to specify borders that surround all or part of a cell, row, row group, column, and column group. Note that mandoc.css says "table { border-collapse: collapse; }", so the above applies. The whole *row* is supposed to be surrounded, not just the element. Also, https://validator.w3.org/nu/ does not show any warnings except asking for a "lang" attribute of the element. So, i believe what mandoc emits is correct and unambiguous - if it is not, i'd appreciate clues what is wrong and how to fix it. >>> Below is output from GNU man, which I believe is correct: [...] I agree that rendering is correct. It also matches what mandoc -Tutf8 and -Tascii produce now. >> Now I tested Firefox and Konqueror browsers too. And they rendered those >> missing horizontal lines... Output is exactly same as like GNU man >> terminal output. Yes, i think Firefox renders the mandoc output correctly. >> So it is just problem in Chromium 70? It seems so to me, but i'm not a specialist for web technologies, so if anyone here knows better, please speak up. > And in all browsers I see another suspicious thing. Vertical lines in > the middle of the table are black and horizontal lines are gray or > rather dark gray (but not black). Border around whole table is also > gray. > > Is this intended? No, it is not intended, all lines seem black and of equal width to me in Firefox 62.0.2 on OpenBSD-current. Neither the HTML emitted by mandoc nor mandoc.css makes any statement about the color or width of the lines. That is intentional: neither does the tbl(7) input code, and i believe that when styling, it is best to only style what you intend to style and leave the rest at the default or user settings. I don't see why any browser would render any of the lines in gray, though, and even less so in two different colors. https://www.w3.org/TR/CSS2/tables.html doesn't seem to say anything specific about color, so i'd expect https://www.w3.org/TR/CSS2/colors.html to apply, which says: 'color' Value: | inherit Initial: depends on user agent but whatever the initial value for a root element, it should be inherited by all children alike, as far as i can see, so the borders should be the same color as the text. Firing up "Web Developer >> Inspector" in Firefox 62.0.2 and enabling "Browser Styles", i do indeed see "border-bottom-color: rgb(0, 0, 0);" for the
B
A2
elements contained in that
elements that happen to be contained in the associated
and all its children, as expected. So i fear i do not know how i could improve the mandoc output... Yours, Ingo -- To unsubscribe send an email to discuss+unsubscribe@mandoc.bsd.lv