From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Patrice Dumas Newsgroups: gmane.comp.tex.texinfo.bugs,gmane.emacs.devel Subject: Re: texi2html output validity Date: Tue, 23 Dec 2014 17:49:11 +0100 Message-ID: <20141223164911.GD5623@free.fr> References: <87h9wqimf0.fsf@fencepost.gnu.org> <87y4q1fekv.fsf@fencepost.gnu.org> <87k31kga2y.fsf@fencepost.gnu.org> <87r3vsdps7.fsf@fencepost.gnu.org> <87a92ehctk.fsf_-_@violet.siamics.net> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1419353396 14554 80.91.229.3 (23 Dec 2014 16:49:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 23 Dec 2014 16:49:56 +0000 (UTC) Cc: bug-texinfo@gnu.org, Emacs developers To: Yuri Khan Original-X-From: bug-texinfo-bounces+gnu-bug-texinfo2=m.gmane.org@gnu.org Tue Dec 23 17:49:50 2014 Return-path: Envelope-to: gnu-bug-texinfo2@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Y3Seb-0000Zt-1r for gnu-bug-texinfo2@m.gmane.org; Tue, 23 Dec 2014 17:49:49 +0100 Original-Received: from localhost ([::1]:45419 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y3Sea-0001L8-IF for gnu-bug-texinfo2@m.gmane.org; Tue, 23 Dec 2014 11:49:48 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42749) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y3SeS-0001L3-4E for bug-texinfo@gnu.org; Tue, 23 Dec 2014 11:49:47 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Y3SeK-0006Cr-Je for bug-texinfo@gnu.org; Tue, 23 Dec 2014 11:49:40 -0500 Original-Received: from saturne.centre-cired.fr ([193.51.120.234]:53635) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y3SeK-0006Cc-Au; Tue, 23 Dec 2014 11:49:32 -0500 Original-Received: from patoune (poseidon.centre-cired.fr [193.51.120.9]) (authenticated bits=0) by saturne.centre-cired.fr (8.14.4/8.14.4) with ESMTP id sBNGgKoe021011; Tue, 23 Dec 2014 17:42:37 +0100 Mail-Followup-To: Patrice Dumas , Yuri Khan , bug-texinfo@gnu.org, Emacs developers Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-12-10) X-Miltered: at saturne.centre-cired.fr with ID 54999B6C.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (saturne.centre-cired.fr [193.51.120.234]); Tue, 23 Dec 2014 17:42:37 +0100 (CET) X-MIME-Autoconverted: from 8bit to quoted-printable by saturne.centre-cired.fr id sBNGgKoe021011 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 193.51.120.234 X-BeenThere: bug-texinfo@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Bug reports for the GNU Texinfo documentation system List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-texinfo-bounces+gnu-bug-texinfo2=m.gmane.org@gnu.org Original-Sender: bug-texinfo-bounces+gnu-bug-texinfo2=m.gmane.org@gnu.org Xref: news.gmane.org gmane.comp.tex.texinfo.bugs:6981 gmane.emacs.devel:180577 Archived-At: Hello, First of all it is a bit unclear where this html comes from. In general, both texi2html and texi2any/makeinfo, especially for makeinfo starting at version 5 render properly nested html tags. =20 On Tue, Dec 23, 2014 at 09:29:07PM +0700, Yuri Khan wrote: > > > > =E2=80=A2 the element is /always/ used instead of ; >=20 > Cursory reading of HTML.pm seems to indicate that is currently*** > used for @key, @t, @verb, and some kinds of tables possibly related to > @example, @smallexample, @lisp and @smalllisp. Use of in @example, @smallexample, @lisp and @smalllisp is for very special case, something like a @table nested in those formats. > *** 5.2.0.dfsg.1-2 as packaged in Ubuntu 14.04 >=20 > @key should be rendered as , possibly with an additional class. > Yes, even when inside @kbd =E2=80=94 HTML allows and encourages nesting= . I am not convinced. @key is semantically very diferent from @kbd which is the same as . Indeed is not for a keyboard key in HTML, but for typed keyboard input. > @t is a non-semantic command in Texinfo and should probably be > discouraged the same way has been discouraged in HTML since at > least 1997. It probably should become a styled with > .t { font-family: monospace }. @t and other non-semantic commands are already discouraged in the manual. But I see no point in not using for @t, as long as browser support it (which is likely to be until the end of times). CSS is not supported by every browser. > @verb is syntax sugar for escaping characters which have special > meaning in Texinfo, and has a non-semantic side effect of fixed-width > rendering. It probably should become a . Once again this will only work if there is CSS support. should always work. That being said, the best could be . > Code examples are a good match for . >=20 > > =E2=80=A2 is r= eplaced with > > ; >=20 > No. { border: 0 } should just be specified in CSS for all img, while > alignment should be handled by classes. >=20 > > =E2=80=A2 unless there=E2=80=99s a really good reason to nest=

inside an > > , =E2=80=93 do it in reverse:

; f= or one thing, this > > makes it possible to simply omit any

s on output. >=20 > +1 for nesting within

. -1 against omitting closing tags. If non valid HTML is emitted by makeinfo it is a bug, so no closing tag omissions, no invalid nesting. A

in should be pretty rare, I cannot really imagine Texinfo code that would lead to that. But if you have such code, don't hesitate to report it, we'll see what we can do. > Note also that and /

nesting order are just the tip of the > iceberg. The wider problem is that the Texinfo HTML generator > generally assumes HTML =E2=89=883.2 even though it declares 4.01 Transi= tional: No, there is a special code for HTML 3.2 compatibility, in init/html32.pm, but in HTML.pm many 4.01 features are used. I may have missed something, but in the specification of 4.01 Transitional all the element you describe as needing to be dropped are accepted? I see them all in http://www.w3.org/TR/html401/sgml/loosedtd.html Also, I think that, at least in the past, I checked the validity of texi2html/makinfo output with some program and the HTML was valid. We in fact choose that DTD in order to have a good rendering both in old and new browser, with or without CSS. > * should be dropped in favor of placing an id on the parent el= ement; > * alignment should be handled by classes; > * , ,
align=3D=E2=80=A6> should be replaced with CSS; The previous 3 items seems to me to be ok in 4.01 Transitional. > * tables should be generally avoided unless actually representing tabul= ar data; Agreed, but sometime we want to do some non-semantic formatting, for instance for node lines, or indices. is very practical in that case. > * table cells containing only non-breaking spaces indicate some > problem that should be solved, not worked around; > * a non-breaking space immediately adjacent to a normal space is nonsen= sical; > * more than one contiguous non-breaking space is a kludge; Same as above, the use of non breaking spaces is for cases when we want non-semantic formatting. I agree that these are kludges, but current output is rendered ok on all browsers we know about. If there are proposals of other formatting that can be used optionnally and do not involve tables and non breaking spaces, and involve, for instance CSS, don't hesitate to propose. But it will be optional, the default is likely to be the kludges, as long as they render nicely. > *
are fit for poetry and postal addresses and almost nothing else; We use it for @* and @sp as the semantics correspond. Otherwise it is rarely used, and always in cases when we do some non-semantic formatting (author name, in indices formatting). > * should be replaced with CSS; > * OUTPUT_ENCODING_NAME should be deprecated in favor of UTF-8; Default is utf-8 already, so no need to prevent setting OUTPUT_ENCODING_NAME. But otherwise we must stick to what the user provides as @documentencoding. > * the encoding declaration should be the first thing in ; What would be the reason for that? --=20 Pat