From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Yuri Khan Newsgroups: gmane.comp.tex.texinfo.bugs,gmane.emacs.devel Subject: Re: texi2html output validity Date: Wed, 24 Dec 2014 00:59:32 +0700 Message-ID: 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> <20141223164911.GD5623@free.fr> 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 1419357599 17887 80.91.229.3 (23 Dec 2014 17:59:59 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 23 Dec 2014 17:59:59 +0000 (UTC) To: Patrice Dumas , Yuri Khan , bug-texinfo@gnu.org, Emacs developers Original-X-From: bug-texinfo-bounces+gnu-bug-texinfo2=m.gmane.org@gnu.org Tue Dec 23 18:59:54 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 1Y3TkP-0003Q3-3B for gnu-bug-texinfo2@m.gmane.org; Tue, 23 Dec 2014 18:59:53 +0100 Original-Received: from localhost ([::1]:45726 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y3TkO-0000yb-Lj for gnu-bug-texinfo2@m.gmane.org; Tue, 23 Dec 2014 12:59:52 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37318) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y3TkA-0000X9-8o for bug-texinfo@gnu.org; Tue, 23 Dec 2014 12:59:39 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Y3Tk5-000140-HJ for bug-texinfo@gnu.org; Tue, 23 Dec 2014 12:59:38 -0500 Original-Received: from mail-ig0-x236.google.com ([2607:f8b0:4001:c05::236]:37627) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y3Tk5-00013p-B0; Tue, 23 Dec 2014 12:59:33 -0500 Original-Received: by mail-ig0-f182.google.com with SMTP id hn15so5876281igb.9; Tue, 23 Dec 2014 09:59:32 -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:content-type:content-transfer-encoding; bh=YYtXlcoSjv7iHjTIfWVb1VH5H7Z2NBGwGw6YN+VujUY=; b=xALWIDhx5ZhLRXdoYrtBP9n8ZjP97kHx/lDzziSNN5nShSy4fK6CfXMRieQI18Ardk vDCwvfmODK/maxEf0ZiLbrAL2d8es04VNYCUKG+KxI+ifoDrwD78dFNfIz5Y6HnCkObH 5v2TobFQZxb0540y788WwAXp7Txjt4nLLYoGfwWAodlbaKmo+XQ2/mqbIGQNAE3HGjhD c0kX3gylRHdbgfm/ABxw2gv5HxcYq1SK/5daGU2cLd4r5NjKkWv4KkHBNeQVy1MlyzOX 9tCzXQVoKBHjfOiLsGQvgkYZ2Wv9Fi9KywqVq8EFhlOaJgK4voy2yhhi21QnvLSCGLwh CxTw== X-Received: by 10.43.82.72 with SMTP id ab8mr23593661icc.76.1419357572729; Tue, 23 Dec 2014 09:59:32 -0800 (PST) Original-Received: by 10.107.48.82 with HTTP; Tue, 23 Dec 2014 09:59:32 -0800 (PST) In-Reply-To: <20141223164911.GD5623@free.fr> X-Google-Sender-Auth: Fn8jJbpyOIDb6RIl60KxaVg-CKc X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:4001:c05::236 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:6985 gmane.emacs.devel:180586 Archived-At: On Tue, Dec 23, 2014 at 10:49 PM, Patrice Dumas wrote: > 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. I haven=E2=80=99t checked. David Kastrup posted it as an example of how ima= ge size is not declared, and I just assumed it was real Texinfo output. >> @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. http://www.w3.org/TR/html5/text-level-semantics.html#the-kbd-element says: > When the kbd element is nested inside another kbd element, it represents = an actual key or other single unit of input as appropriate for the input me= chanism. > @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. What browsers are there that do not support CSS *and* at the same time have the capability of displaying proportional fonts? Anyway this point is moot because the current HTML specification makes CSS the only supported way of specifying presentation. Browsers that do not yet support CSS had better keep up. > 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 Yes, 4.01 Transitional allowed all that. That=E2=80=99s why it was named Transitional =E2=80=94 to provide backward compatibility for the transition period. As of this past October, that transition period is over. HTML 3.2 is obsolete and so is 4.01 Transitional. 4.01 Strict remains an almost-compatible subset of the current standing Recommendation, HTML 5. >> * tables should be generally avoided unless actually representing tabula= r 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. Non-semantic formatting is bad. Please do not want to do it. I do not understand what node lines are. I thought a node is a whole section of a document? Indices would look much better as definition lists, possibly styled for compact presentation on viewports wider than a certain threshold, and possibly using multicolumn layout on even wider viewports. I tested the Emacs manual index[1] in the Responsive Design View mode in Firefox: it fits the 320=C3=97480 screen very poorly and under-utilizes the 1920=C3=971200 screen. [1]: http://www.gnu.org/software/emacs/manual/html_node/emacs/index.html >> * the encoding declaration should be the first thing in ; > > What would be the reason for that? Because the HTML specification says[2] the encoding declaration must appear within the first 1024 bytes of the document, and including any kind of document-provided content before the encoding declaration might cause a violation of this rule. [2]: http://www.w3.org/TR/html5/document-metadata.html#charset1024 And the reason for HTML spec saying so is that if the parser does not know the encoding beforehand, it then has to perform a preliminary scanning of the document in search of an encoding declaration. After it finds one, it has to restart at the beginning. Restarting the parsing could be very inefficient if the document is being streamed from the network.