From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp-4.sys.kth.se (smtp-4.sys.kth.se [130.237.48.193]) by krisdoz.my.domain (8.14.5/8.14.5) with ESMTP id s7ABe5Hh020703 for ; Sun, 10 Aug 2014 07:40:05 -0400 (EDT) Received: from smtp-4.sys.kth.se (localhost.localdomain [127.0.0.1]) by smtp-4.sys.kth.se (Postfix) with ESMTP id B5A43125 for ; Sun, 10 Aug 2014 13:40:04 +0200 (CEST) X-Virus-Scanned: by amavisd-new at kth.se Received: from smtp-4.sys.kth.se ([127.0.0.1]) by smtp-4.sys.kth.se (smtp-4.sys.kth.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id PJfBJ3Cyv7Px for ; Sun, 10 Aug 2014 13:40:03 +0200 (CEST) X-KTH-Auth: kristaps [2a02:1205:5033:5b0:7581:aa34:5995:71bd] X-KTH-mail-from: kristaps@bsd.lv X-KTH-rcpt-to: discuss@mdocml.bsd.lv Received: from [IPv6:2a02:1205:5033:5b0:7581:aa34:5995:71bd] (unknown [IPv6:2a02:1205:5033:5b0:7581:aa34:5995:71bd]) by smtp-4.sys.kth.se (Postfix) with ESMTPSA id 9CA0B1BAD for ; Sun, 10 Aug 2014 13:39:53 +0200 (CEST) Message-ID: <53E75A07.2070907@bsd.lv> Date: Sun, 10 Aug 2014 13:39:51 +0200 From: Kristaps Dzonsons User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 X-Mailinglist: mdocml-discuss Reply-To: discuss@mdocml.bsd.lv MIME-Version: 1.0 To: discuss@mdocml.bsd.lv Subject: Re: HTML5 References: <53E6AFDD.8010001@bsd.lv> <20140810022307.GC32716@iris.usta.de> In-Reply-To: <20140810022307.GC32716@iris.usta.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Ingo, Anthony, > Let me put it this way: We should not use any fancy features. > If somebody has a browser that doesn't know about HTML versions > and just assumes everything is HTML 4 without looking at any > document types and stuff, then the pages should render cleanly. > Whether or not they validate as HTML 5 seems irrelevant to me. > > Supporting multiple HTML variants seems pointless to me and just > complicates the code. I agree. In short, unifying under HTML5 will simplify the code (no switching)--that much is clear. I don't care whether it's HTML5 or asciidoc so long as it gets the job done. And for browsers, it's between flavours of HTML. So let's consider why HTML5 instead of just HTML4 or XHTML1 as-is. First, note that the patch's HTML5 is called "polyglot" HTML5, which is to say, HTML5 with XML syntax. (Link: .) A "pro" is that polyglot HTML5 has the same doctype *and content type* for its XHTML and HTML modes. So we can create well-formed, parseable HTML5 mark-up using strict XML syntax, then serve it with text/html and be happily standards-compliant. As it is, we put a burden on the agency serving -Thtml or -Txhtml pages to know the difference. The "con" is that by unifying -Thtml/xhtml as HTML5--or anything, really--we lose strict HTML4 callers of -Ofragment (XHTML1 callers would be fine). The only caller right now is cgi.c, which stipulates HTML4. This can be fixed easily: remove the HTML4 parts of to cgi.c's DOCTYPE and close the void img, meta, and link elements. See the "pro" above for why that's also a smart idea. Another "pro" is that we get eqn. Ingo, this is the "feature" you're worried about. And it's a pretty big issue for me (so this is a "for me"): all of my equations (in eqn, or really in DocBook--which I use with docbook2mdoc for some scientific applications--which I'd like to convert into eqn) are lost. Also lost are LAPACK manuals, OpenGL, and a host of other eqn systems. If we stick to HTML4, we'd need to cripple ourselves with table-based equations. If we stick with XHTML1, we need to jump through namespace hoops. But with HTML5, we get embedded MathML. The "con", yes, is that MathML is a scary feature, and it doesn't exist yet. YET. At the end of the day, the browser doesn't really care whether it's HTML4, XHTML1, or HTML5. It'll render regardless. Callers of -Ofragment will care, but right now that's just us. Ingo, you mentioned non-conforming browsers. Care to point me to one that will puke on the HTML5 output from the patch? Even lynx(1) can read that! If we're really at loggerheads over it, /adding/ HTML5 is as easy as another switch statement of two. I think it's a good idea regardless of whether it's added or replacing for the reasons above. ...on to other matters: the style-sheet. The status quo bugs me because of the header and footer table. These have hard-coded widths and alignments to make them look decent without a stylesheet. This is inadvisable in any modern flavour of HTML. At the very least, we should replace the "width" and "height" for embedded styles. Unfortunately, that's a problem: inline styles can't be overriden without the "!important" qualifier in CSS, which is annoying. (That's why I used the width attributes in the first place.) So I think that putting just the table styles *before* the is a good idea. The question goes: if we're going to do that, is there anything else that should go there? The stylesheet I put in place does serve an important purpose: it prevents overriding styles. In man(7) and mdoc(7), for example, you can't have overlapping styles. E.g., .Bf Sy Hi .Ar there .Ef The "there" doesn't have both styles: they reset when they're nested. (There are probably better ways to do it in CSS, but it needs to be done one way or another.) Without some sort of style-sheet, font modes will be nested. Yes, I'm at conflict with myself: on the one hand, mdoc(7) does this because consoles generally haven't supported overlapping fonts, and I don't like console hold-vers in HTML output. Or should we discard that convention? (groff's -Tps does it too!) And yes, I agree that we should just have a single stylesheet in the source. I don't particularly care what it shows. Best, Kristaps -- To unsubscribe send an email to discuss+unsubscribe@mdocml.bsd.lv