From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: Alternative input formats Date: Mon, 08 Dec 2014 12:42:30 +0900 Message-ID: <8761dmkdsp.fsf@uwakimon.sk.tsukuba.ac.jp> References: <20141205123549.GA29331@thyrsus.com> <2815659.zRQ0WWWeRr@descartes> <20141205175810.GD3120@thyrsus.com> <87wq66ufyt.fsf@wanadoo.es> <87tx18vl0v.fsf@dod.no> <87iohnvh3m.fsf@dod.no> <877fy3lmm4.fsf@violet.siamics.net> <877fy3vcw4.fsf@dod.no> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: ger.gmane.org 1418010193 10734 80.91.229.3 (8 Dec 2014 03:43:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 8 Dec 2014 03:43:13 +0000 (UTC) Cc: Steinar Bang , Richard Stallman , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Dec 08 04:43:06 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 1XxpE0-0001q4-VT for ged-emacs-devel@m.gmane.org; Mon, 08 Dec 2014 04:43:05 +0100 Original-Received: from localhost ([::1]:59961 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XxpE0-0002ZF-DJ for ged-emacs-devel@m.gmane.org; Sun, 07 Dec 2014 22:43:04 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34678) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XxpDf-0002Yx-Pw for emacs-devel@gnu.org; Sun, 07 Dec 2014 22:42:51 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XxpDX-0003fp-Mr for emacs-devel@gnu.org; Sun, 07 Dec 2014 22:42:43 -0500 Original-Received: from shako.sk.tsukuba.ac.jp ([130.158.97.161]:42762) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XxpDX-0003fO-Cm; Sun, 07 Dec 2014 22:42:35 -0500 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id C6A751C38CB; Mon, 8 Dec 2014 12:42:30 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 832F31A2CFC; Mon, 8 Dec 2014 12:42:30 +0900 (JST) In-Reply-To: X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 130.158.97.161 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:179358 Archived-At: Stefan Monnier writes: > But getting this within Emacs, for "full HTML" sounds pretty difficult, > both because of limitations of Emacs's redisplay code, and because "full > HTML" nowadays goes much beyond the SGML markup language and includes > Javascript along with a large runtime library. > > So it would necessarily have to be limited to a specific subset of > HTML. How about calling the subset "InfoML, the Info-featured HTML subset"? It would also need to spec a CSS subset, I think (see below). I don't think anybody has asked for "full HTML" (and definitely not "full HTML5", although some HTML5 features might be nice). Certainly the necessary navigation features are easy to implement in Emacs Lisp. The Emacs Lisp InfoML browser can provide them natively, and ignore the Ecmascript functions that conventional browsers would probably use to support navigation. Other than that we need faces, and I would suggest prohibiting EM (and I!) and STRONG (ditto B!) elements in favor of semantic markup on DIV and SPAN elements ('class="nextNode"' and the like). Then the conventional browsers would get appropriate CSS. Again, the Emacs Lisp InfoML browser can ignore the CSS, at least at first. And links, but Emacs already knows how to do that. It's not going to require new features from Emacs, but it's not done yet, and there does need to be a spec for the subset. And the Ecmascript and CSS for conventional browsers would also need to be written.