From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f68.google.com (mail-wr1-f68.google.com [209.85.221.68]) by fantadrom.bsd.lv (OpenSMTPD) with ESMTP id 0126c065 for ; Mon, 3 Dec 2018 17:01:46 -0500 (EST) Received: by mail-wr1-f68.google.com with SMTP id j10so13803131wru.4 for ; Mon, 03 Dec 2018 14:01:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=RhZe7g7jHiLfk9w1+wlvZR9bPTNuL+maboQ6YNZbDUE=; b=kRjUFlHMBjxx7Wzh80r1WlE5C+rQX+eM8wLL8e3heBA9AxR6VNYgiGdADyKEbPEfKJ Cc/zsAfGubK38no60nhAatANyCjq7IA3l2ps4Zv3xNkhq56rdUXfiTNw690gMrRXXYLY R4PI5350Hb/zlJfjdjIQjeVX2Ai25sRUKrzwBf/A3Noi1Uppi311CaGd+Hg245vrqh8v DVG0ZcjygMiJFWTRw1enbJ6vAv7aWm2HWtg/gao2cqsyhdKYeXdFNh9Oerp3hR95gR6R n1/tKATxFPeTqQCA6xRCCExdJYRF7RIjqvqwHiXMNFfOsSTKLG9X9AmZ2jZSEJeGDigP 9JEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=RhZe7g7jHiLfk9w1+wlvZR9bPTNuL+maboQ6YNZbDUE=; b=hnrV/aaT24xlOJagIJYpvFw1B+06lGfC5ZWoWpC2LMBYwhNzq0jU6YFEI9nuE0EyJ+ sdrLkMHvbpk760jKTdlW918g2yw+F9ohXzzveUoFIOXBHxS48mZbGT9NpOkOX9GT3PjQ XCQwnSy0UlWXqs9Xm4100zqluez4WOm001DaSfTzdhf7jkALLJLCVcMve2d3ZM69Gj80 Uns3h+nggWbqMXSg7gSssx4VYnKXkANgKvliTDdYRvmYV0Bed4IkpfMdTwXd+RWl/44c 69M4emPho84HjmPj/NO0wn11ppRMtXgw4gayRPtwvfYQlVya/yG+PFivYWK2BXnJyHvp 0AEw== X-Gm-Message-State: AA+aEWaHZ0Mhmsfjb9feU7pFEXxQ2HtFAC039pMa0ZFgM0NGFLjRgFB6 lkPbO6FeTXZnTsS2fe+aOVc= X-Google-Smtp-Source: AFSGD/WlWEgyeHlS7rH53jbrTCH86h1w+c/FUzOzYyDJOP7qI/+cw3XWywnfMefPPvZoTyvORSd1Qg== X-Received: by 2002:a5d:6889:: with SMTP id h9mr15628954wru.222.1543874505200; Mon, 03 Dec 2018 14:01:45 -0800 (PST) Received: from pali ([2a02:2b88:2:1::5cc6:2f]) by smtp.gmail.com with ESMTPSA id l20sm32902441wrb.93.2018.12.03.14.01.43 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 03 Dec 2018 14:01:43 -0800 (PST) Date: Mon, 3 Dec 2018 23:01:42 +0100 From: Pali =?utf-8?B?Um9ow6Fy?= To: Ingo Schwarze Cc: discuss@mandoc.bsd.lv Subject: Re: Broken tables in HTML output Message-ID: <20181203220142.zj5yxqdmgizsmckp@pali> References: <20180716110335.uusqzhscwdgp5qaa@pali> <20180716152919.GB85992@athene.usta.de> <20181126212728.GG82448@athene.usta.de> <20181126215826.xepdfaas5fm42ubc@pali> <20181126220133.bf7siow6e5mxahhv@pali> <20181126220516.nrflslyvxufb7xnk@pali> <20181201172057.GD89021@athene.usta.de> X-Mailinglist: mandoc-discuss Reply-To: discuss@mandoc.bsd.lv MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="iqkfhxbcqrcwmvjy" Content-Disposition: inline In-Reply-To: <20181201172057.GD89021@athene.usta.de> User-Agent: NeoMutt/20170113 (1.7.2) --iqkfhxbcqrcwmvjy Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Saturday 01 December 2018 18:20:57 Ingo Schwarze wrote: > Hi Pali, >=20 > 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: >=20 > >>> I tested new cvs changes for following table: >=20 > >>> .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 >=20 > The table syntax looks sane to me. >=20 > >>> 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 B= 1. > >>> And not across whole line. >=20 > The rendering in the PNG file you attached seems broken in multiple > respects: >=20 > * The outer border of the table as a whole is rendered as "double", > even though the mandoc HTML output clearly says: >=20 > >=20 > * Same for the horizontal line between B and C: >=20 > > >=20 > * Same for the horizontal line between A and B: >=20 > > > >=20 > So whatever produced that PNG file seems quite broken. >=20 > 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. >=20 > On https://www.w3.org/TR/html/tabular-data.html > the algorithm for processing rows says in step 13: >=20 > Let the slots with coordinates (x, y) > such that xcurrent <=3D x < xcurrent+colspan > and ycurrent <=3D 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. >=20 > 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_. >=20 > And right below "4.9.12. Processing model" it says: >=20 > A row is a complete set of slots from x=3D0 to x=3Dxwidth-1, > for a particular value of y. >=20 > And https://www.w3.org/TR/CSS2/tables.html says > below "17.6.2 The collapsing border model": >=20 > 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. >=20 > 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. >=20 > Also, https://validator.w3.org/nu/ does not show any warnings > except asking for a "lang" attribute of the element. >=20 > 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. >=20 > >>> Below is output from GNU man, which I believe is correct: > [...] >=20 > I agree that rendering is correct. > It also matches what mandoc -Tutf8 and -Tascii produce now. >=20 > >> Now I tested Firefox and Konqueror browsers too. And they rendered tho= se > >> missing horizontal lines... Output is exactly same as like GNU man > >> terminal output. >=20 > Yes, i think Firefox renders the mandoc output correctly. >=20 > >> So it is just problem in Chromium 70? >=20 > It seems so to me, but i'm not a specialist for web technologies, > so if anyone here knows better, please speak up. Seems that it is needed to put "border-bottom-style: solid" for rowspanned td element. At least this is working in chrome. And after playing a bit I was not able to achieve visible border when was specified for tr element. It is possible such change in mandoc generator? I understand that current HTML output is (or you think) correct, but is unusable in chrome browser. And chrome is one of the major browsers, so it should not be ignored. --=20 Pali Roh=C3=A1r pali.rohar@gmail.com --iqkfhxbcqrcwmvjy Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABECAB0WIQS4VrIQdKium2krgIWL8Mk9A+RDUgUCXAWnxAAKCRCL8Mk9A+RD UiGLAKDAXKfGc6xj+o4gYcTjEhz+QaB6ZACeNn81EbHT3lox05M9Sp/qKHHrEX8= =qOj9 -----END PGP SIGNATURE----- --iqkfhxbcqrcwmvjy-- -- To unsubscribe send an email to discuss+unsubscribe@mandoc.bsd.lv
B
A2
> elements contained in that
elements that happen to be contained in the > associated