From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.0 required=5.0 tests=T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 27915 invoked from network); 3 Jul 2022 17:24:22 -0000 Received: from bsd.lv (HELO mandoc.bsd.lv) (66.111.2.12) by inbox.vuxu.org with ESMTPUTF8; 3 Jul 2022 17:24:22 -0000 Received: from fantadrom.bsd.lv (localhost [127.0.0.1]) by mandoc.bsd.lv (OpenSMTPD) with ESMTP id 740a7db5 for ; Sun, 3 Jul 2022 12:24:20 -0500 (EST) Received: from scc-mailout-kit-02.scc.kit.edu (scc-mailout-kit-02.scc.kit.edu [129.13.231.82]) by mandoc.bsd.lv (OpenSMTPD) with ESMTP id b4f4abdb for ; Sun, 3 Jul 2022 12:24:19 -0500 (EST) Received: from hekate.asta.kit.edu ([2a00:1398:5:f401::77]) by scc-mailout-kit-02.scc.kit.edu with esmtps (TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (envelope-from ) id 1o83KT-0082vk-SS; Sun, 03 Jul 2022 19:24:18 +0200 Received: from login-1.asta.kit.edu ([2a00:1398:5:f400::72]) by hekate.asta.kit.edu with esmtp (Exim 4.94.2) (envelope-from ) id 1o83KS-006HOi-39; Sun, 03 Jul 2022 19:24:16 +0200 Received: from schwarze by login-1.asta.kit.edu with local (Exim 4.92) (envelope-from ) id 1o83KS-0000fY-FF; Sun, 03 Jul 2022 19:24:16 +0200 Date: Sun, 3 Jul 2022 19:24:16 +0200 From: Ingo Schwarze To: Anna Cc: tech@mandoc.bsd.lv Subject: Re: [PATCH 1/3] Wrap manual header in the "
" tag Message-ID: References: <20220628181844.15484-1-cyber@sysrq.in> <20220628181844.15484-2-cyber@sysrq.in> X-Mailinglist: mandoc-tech Reply-To: tech@mandoc.bsd.lv MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20220628181844.15484-2-cyber@sysrq.in> Hello Anna, Anna Vyalkova wrote on Tue, Jun 28, 2022 at 11:18:42PM +0500: [...] > diff --git a/mandoc.css b/mandoc.css > index 73f5c668..4cfb51e8 100644 > --- a/mandoc.css > +++ b/mandoc.css > @@ -53,7 +53,8 @@ table.results { margin-top: 1em; > > /* Header and footer lines. */ > > -table.head { width: 100%; > +header > table { > + width: 100%; > border-bottom: 1px dotted #808080; > margin-bottom: 1em; > font-size: smaller; } > diff --git a/mdoc_html.c b/mdoc_html.c > index a0e29c72..cf771b75 100644 > --- a/mdoc_html.c > +++ b/mdoc_html.c > @@ -470,7 +470,7 @@ mdoc_root_post(const struct roff_meta *meta, struct html *h) > static int > mdoc_root_pre(const struct roff_meta *meta, struct html *h) > { > - struct tag *t, *tt; > + struct tag *th, *t, *tt; > char *volume, *title; > > if (NULL == meta->arch) > @@ -485,6 +485,7 @@ mdoc_root_pre(const struct roff_meta *meta, struct html *h) > mandoc_asprintf(&title, "%s(%s)", > meta->title, meta->msec); > > + th = print_otag(h, TAG_HEADER, ""); > t = print_otag(h, TAG_TABLE, "c", "head"); > tt = print_otag(h, TAG_TR, ""); > > @@ -499,6 +500,7 @@ mdoc_root_pre(const struct roff_meta *meta, struct html *h) > print_otag(h, TAG_TD, "c", "head-rtitle"); > print_text(h, title); > print_tagq(h, t); > + print_tagq(h, th); > > free(title); > free(volume); I fully agree that the current is insufficient because it has no ARIA effect. I also agree that using
is not wrong because the HTML standard defines it very vaguely: https://html.spec.whatwg.org/multipage/sections.html#the-header-element The header element represents a group of introductory or navigational aids. However, according to the HTML-ARIA standard, the default role of
is "banner" if it is a child of , and "banner" is the wrong role because WAI-ARIA defines it as follows: https://www.w3.org/TR/wai-aria-1.1/#banner A region that contains mostly site-oriented content, rather than page-specific content. Site-oriented content typically includes things such as the logo or identity of the site sponsor, and a site-specific search tool. A banner usually appears at the top of the page and typically spans the full width. The table in question is clearly page-specific and definitely not the same for all documents on the site. I really think we should better use the role "doc-pageheader" here and not "banner". We might of course consider using
, but that would seem unfortunate to me because in the case of man.cgi(8) output, we really need the "banner" role (ideally getting it as the default from a header element) for the site name (e.g. "OpenBSD manual page server") and the search form ("Manual Page Search Parameters"). Using
for *that* would perfectly fit the definition of the "banner" role cited above. As far as i can see, the HTML standard does not prohibit having two
elements in a row, for example like this:

OpenBSD manual page server

...

PF.CONF(5) File Formats Manual PF.CONF(5)
But that would seem ugly to me. Or do you think having two consecutive
elements here would be fine? https://stackoverflow.com/questions/21655804/html5-multiple-footers-headers-in-a-section (which is of course not authoritative) says There is no prohibition against having e.g. two header elements (at the same level of nesting) in an article element. They would then both contain “introductory content” for it. It is however difficult to imagine situations where this would make sense, since header elements normally precede other content, and the header would thus be adjacent and could be combined into one. Here, they could not easily be combined into one because the search form is written by cgi.c whereas the is written by html.c. That's not just an implementation detail because both headers serve a significantly different purpose: the first one presents site-oriented content, the second one is specific to the manual page being shown. Do you think having two consecutive headers right below would be good here, or what should we do instead? If so, should we maybe explicitly set
on the first header even though that is redundant, to make it more apparent why we have two headers? For the footer, using
poses fewer problems because we only need one single footer. But i'd like to solve the trickier case of the headers first before deciding how to mark up the footer. Yours, Ingo -- To unsubscribe send an email to tech+unsubscribe@mandoc.bsd.lv