From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailout.scc.kit.edu (mailout.scc.kit.edu [129.13.185.202]) by krisdoz.my.domain (8.14.5/8.14.5) with ESMTP id s7ENosSl023226 for ; Thu, 14 Aug 2014 19:50:55 -0400 (EDT) Received: from hekate.usta.de (asta-nat.asta.uni-karlsruhe.de [172.22.63.82]) by scc-mailout-02.scc.kit.edu with esmtp (Exim 4.72 #1) id 1XI4nC-0000jl-5J; Fri, 15 Aug 2014 01:50:50 +0200 Received: from donnerwolke.usta.de ([172.24.96.3]) by hekate.usta.de with esmtp (Exim 4.77) (envelope-from ) id 1XI4nC-00082Z-2T; Fri, 15 Aug 2014 01:50:50 +0200 Received: from iris.usta.de ([172.24.96.5] helo=usta.de) by donnerwolke.usta.de with esmtp (Exim 4.72) (envelope-from ) id 1XI4nC-0005J5-0g; Fri, 15 Aug 2014 01:50:50 +0200 Received: from schwarze by usta.de with local (Exim 4.77) (envelope-from ) id 1XI4mR-0000Yz-Bn; Fri, 15 Aug 2014 01:50:03 +0200 Date: Fri, 15 Aug 2014 01:50:02 +0200 From: Ingo Schwarze To: Kristaps Dzonsons Cc: tech@mdocml.bsd.lv Subject: Re: HTML5 redux Message-ID: <20140814235002.GM29858@iris.usta.de> References: <53EBE549.2000100@bsd.lv> <20140814012540.GI26534@iris.usta.de> <53ED1B85.6070202@bsd.lv> X-Mailinglist: mdocml-tech Reply-To: tech@mdocml.bsd.lv MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53ED1B85.6070202@bsd.lv> User-Agent: Mutt/1.5.21 (2010-09-15) Hi Kristaps, Kristaps Dzonsons wrote on Thu, Aug 14, 2014 at 10:26:45PM +0200: > Ingo Schwarze wrote: >> Kristaps Dzonsons wrote: >>> With this patch, both -Thtml and -Txhtml will produce HTML5. This >>> can be disabled in html.c by replacing the HTML_HTML5 allocation >>> with the respective type. The resulting HTML5 validates just fine, >>> as do the existing modes (if replaced in html.c). >> Not for me, there is one regression. >> But if you remove the chunk cited below, the regression goes >> away, so i'd say, go ahead - in particular if you plan to do the >> cleanup right afterwards. > This is a bit trickier than appears. I fear i don't follow where the problem is. What i'm saying is that -

output is valid when you leave the HTML_NOSTACK in place -

output is (often, not always) invalid when you delete it > Basically,

doesn't exist in HTML5 because

isn't a void > element. Sure. However, i don't see how that is relevant. For HTML5, html.c never generates

no matter what we do with HTML_NOSTACK. Two remarks regarding HTML_AUTOCLOSE: 1) It is obsolete. It is set if and only if HTML_NOSTACK is set, so one flag would suffice. 2) After the full switch to HTML5, it is obsolete for a second reason: it is never used for anything in HTML5 mode. Already now, the only place where it is used for syntactically significant output, in print_otag(), is only executed when HTML_XHTML_1_0_STRICT is set. > However, we can't just remove the auto-close parts of

> because then we might have > >

> Hello >

world
>

> > Which is invalid. Exactly what is said. But wy don't we just leave the HTML_NOSTACK as it is now? > http://www.w3.org/TR/html-markup/p.html#p > > In short, mdoc(7) and man(7) can have all sorts of nested block > scopes, and so can HTML, but

can't contain flow elements. Sure. It just ends implicitly when a flow element begins. > I think it's best, and cleanest, to just avoid

and use

, > say as
. I don't understand which problem you think that might solve. But it would make producing well-formed HTML5 output harder, not easier. Because, if you make .Pp a
, how do you know when to close it out? It don't say you cannot come up with a working algorithm, you certainly can. But you just make it harder than if you just open it and never ever close it again. > I understand we lose whatever semantic-ness may be acquired from >

, but I don't think it's much of a loss Actually, it is no loss at all, since .Pp is *not* implemented as a block but as an in_line element. It doesn't mark up any content in any way, it just says "put a paragraph break here", exactly like .br says "put a line break here". > given that, with a classed

, we'll have *real* semantics > (the flow elements will be within the paragraph). I have no idea what the advantage would be... > Naturally, this would work happily with HTML4 just as it > would with HTML5. So does what we have now as far as i can see. > I'll work on a patch and will submit it soon... Actually, there is one problem with

, or rather, with 

.
The .Bd block is marked up as 
, which can only contain
phrasing, but .Bd can contain all sorts of blocks and .Pp.
But that's unrelated to the HTML5 switch.

Yours,
  Ingo
--
 To unsubscribe send an email to tech+unsubscribe@mdocml.bsd.lv