From mboxrd@z Thu Jan 1 00:00:00 1970 From: Wanrong Lin Subject: Re: Re: Blank lines in literal html Date: Sun, 09 Dec 2007 20:57:20 -0500 Message-ID: <475C9D00.2010406@gmail.com> References: <475453D3.30604@gmail.com> <4756FC88.1050701@gmail.com> <878x44ekw6.fsf@bzg.ath.cx> <475C7586.9010105@gmail.com> <87mysjbdir.fsf@bzg.ath.cx> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1J1Xte-0003Fs-Qg for emacs-orgmode@gnu.org; Sun, 09 Dec 2007 20:57:26 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1J1Xtd-0003ED-Ca for emacs-orgmode@gnu.org; Sun, 09 Dec 2007 20:57:26 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1J1Xtc-0003Ds-Ve for emacs-orgmode@gnu.org; Sun, 09 Dec 2007 20:57:25 -0500 Received: from py-out-1112.google.com ([64.233.166.179]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1J1Xtc-0003vG-3G for emacs-orgmode@gnu.org; Sun, 09 Dec 2007 20:57:24 -0500 Received: by py-out-1112.google.com with SMTP id a73so3593086pye for ; Sun, 09 Dec 2007 17:57:23 -0800 (PST) In-Reply-To: <87mysjbdir.fsf@bzg.ath.cx> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: org-mode list Bastien wrote: > Wanrong Lin writes: > > >> Thanks for testing. Surely the No.1 priority is to have correct HTML >> syntax. But I think how the page looks comes very close as a second >> priority. >> > > I'm not sure we're speaking about the same thing: I was speaking about > the HTML *source code*, not the HTML page as rendered in a browser. I > think it's okay to be somewhat liberal about source code readability, > but not about exporting in correct HTML. > > (Note that if both browsers and webpages where both implementing and > respecting W3C specs, then correct rendering and correct syntax would > always come together.) > > Sorry, actually we were talking about different things. Maybe because we have different understandings of the bug itself. Just want to clarify the bug a little bit. Actually, the bug is *NOT* concerned about how the HTML code looks, it is concerned about how the HTML page look. If I put a segment of HTML code in an org file that should display only one blank line, but the exported page displays 3 blank lines in a browser, that page has correct syntax but wrong content (although the rendering is still correct). Because the exported part is bracket in a
 ... 
section, a changed number of blank lines in the HTML code also changes the number of displayed blank lines in the browser.