From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Yuri Khan Newsgroups: gmane.emacs.devel,gmane.comp.tex.texinfo.bugs Subject: Re: texi2html output validity Date: Tue, 23 Dec 2014 21:29:07 +0700 Message-ID: References: <87388bnzha.fsf@newcastle.ac.uk> <87k31mdbhe.fsf@uwakimon.sk.tsukuba.ac.jp> <87tx0qiv45.fsf@fencepost.gnu.org> <87h9wqd3i5.fsf@uwakimon.sk.tsukuba.ac.jp> <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 1419344975 8126 80.91.229.3 (23 Dec 2014 14:29:35 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 23 Dec 2014 14:29:35 +0000 (UTC) Cc: Emacs developers To: bug-texinfo@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Dec 23 15:29:29 2014 Return-path: Envelope-to: ged-emacs-devel@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 1Y3QSk-0006Af-Sb for ged-emacs-devel@m.gmane.org; Tue, 23 Dec 2014 15:29:27 +0100 Original-Received: from localhost ([::1]:44969 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y3QSk-0007L1-72 for ged-emacs-devel@m.gmane.org; Tue, 23 Dec 2014 09:29:26 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40779) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y3QSW-0007KA-RE for emacs-devel@gnu.org; Tue, 23 Dec 2014 09:29:13 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Y3QSV-0006OQ-GU for emacs-devel@gnu.org; Tue, 23 Dec 2014 09:29:12 -0500 Original-Received: from mail-ig0-x232.google.com ([2607:f8b0:4001:c05::232]:34040) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y3QSS-0006NP-Hi; Tue, 23 Dec 2014 09:29:08 -0500 Original-Received: by mail-ig0-f178.google.com with SMTP id hl2so5571069igb.17; Tue, 23 Dec 2014 06:29:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=9D5/fmET3XMIaSofBDxcgxyBkUG6mFsFSE6mkgl0TfU=; b=NMBclVrSUYOZKfAVdfOte2JBW1+wWcDtgNxU6KLsDKVIrsWBHPZZh7YzD5k83iUeZf op6WhaR9Dw7T3lhdB74kTxtmnYpgZ4QZuelRA+wWNIkq4dCCc4yj1nQIp3VIEOQnhMoA /A2DN6+zKZpPKAvS9NiREDltJ/9Uws/fV6vzN7jySuZQ5cLd4AvoZqu3XWcvMWmIKvol pLZy2d2exGcRMi8yUZY2iJoLsqAg3v0yd71LWogmLDWHqbKlsKma9RDPiKwHyQhDO44X fKBlhE7B2EsgOOw8rs/7NG20ajI4hRVCU5YpyTAFq3SCKyWH9D1EqVBAsMITCP/8pBiz bdPg== X-Received: by 10.50.29.107 with SMTP id j11mr21223495igh.32.1419344947738; Tue, 23 Dec 2014 06:29:07 -0800 (PST) Original-Received: by 10.107.48.82 with HTTP; Tue, 23 Dec 2014 06:29:07 -0800 (PST) In-Reply-To: <87a92ehctk.fsf_-_@violet.siamics.net> X-Google-Sender-Auth: KWvmuV3Ys0hRPPQyTbsnjxMDNFY X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:4001:c05::232 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:180559 gmane.comp.tex.texinfo.bugs:6977 Archived-At: On Tue, Dec 23, 2014 at 4:37 PM, Ivan Shmakov wrote: > >>>

‘accidental-ancient.ly<= /tt>’ > >>>

> >>> > >>> >>> border=3D"0" > >>> src=3D"79/lily-83620d4b.png" > >>> alt=3D"[image of music]"> > >>> > >>>

> > >> In this snippet, I count 2 instances of improper tag nesting, > > I count just a single one, but yes, that second

surely > invalidates the fragment.

is improper* nesting in my book. All paired tags SHOULD** be explicitly closed. * note I did not say =E2=80=9Cinvalid=E2=80=9D ** as in RFC2119 > I hereby suggest that: > > =E2=80=A2 the element is /always/ used instead of = ; 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. *** 5.2.0.dfsg.1-2 as packaged in Ubuntu 14.04 @key should be rendered as , possibly with an additional class. Yes, even when inside @kbd =E2=80=94 HTML allows and encourages nesting . @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 }. @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 . Code examples are a good match for . > =E2=80=A2 is repla= ced with > ; No. { border: 0 } should just be specified in CSS for all img, while alignment should be handled by classes. > =E2=80=A2 unless there=E2=80=99s a really good reason to nest

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

; for o= ne thing, this > makes it possible to simply omit any

s on output. +1 for nesting within

. -1 against omitting closing tags. 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 Transition= al: * should be dropped in favor of placing an id on the parent elemen= t; * alignment should be handled by classes; * , ,
should be replaced with CSS; * tables should be generally avoided unless actually representing tabular d= ata; * 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 nonsensica= l; * more than one contiguous non-breaking space is a kludge; *
are fit for poetry and postal addresses and almost nothing else; * should be replaced with CSS; * OUTPUT_ENCODING_NAME should be deprecated in favor of UTF-8; * the encoding declaration should be the first thing in ; * I might have missed something.