From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicolas Goaziou Subject: Re: Bug: New HTML exporter incorrect attributes Date: Mon, 25 Feb 2013 14:49:04 +0100 Message-ID: <87vc9gfqr3.fsf@gmail.com> References: <87fw0nibde.fsf@gmail.com> <871uc4acid.fsf@lapcat.tftorrey.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([208.118.235.92]:58430) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U9yQi-0002A5-TH for emacs-orgmode@gnu.org; Mon, 25 Feb 2013 08:49:22 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U9yQh-0003vz-1f for emacs-orgmode@gnu.org; Mon, 25 Feb 2013 08:49:20 -0500 Received: from mail-wi0-f174.google.com ([209.85.212.174]:48224) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U9yQg-0003vk-QR for emacs-orgmode@gnu.org; Mon, 25 Feb 2013 08:49:18 -0500 Received: by mail-wi0-f174.google.com with SMTP id hi8so3414618wib.7 for ; Mon, 25 Feb 2013 05:49:18 -0800 (PST) In-Reply-To: <871uc4acid.fsf@lapcat.tftorrey.com> (T. F. Torrey's message of "Mon, 25 Feb 2013 03:55:38 -0700") List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: "T.F. Torrey" Cc: emacs-orgmode@gnu.org tftorrey@tftorrey.com (T.F. Torrey) writes: >> It would be ATTR_HTML: :class "XXX". I try to unify syntax for >> attributes with syntax for Babel and AFAICT, `html' is the last back-end >> to have key="value" syntax. > > I see that this does not presently work, and the author listed on > ox-html.el is not currently active on this list. I hope you are not the > only one working on this. It would be our great misfortune for you to > become burned out. It's not much work once we agree about the real syntax. For example, for links, there are two ways to replace: #+ATTR_HTML: width="400px" The easiest one, is simply to ask for `:options' before: #+ATTR_HTML: :options "width=\"400px\"" This is heavier but will be consistent with other back-ends. Otherwise, there is also: #+ATTR_HTML: :width "400px" But this requires to have a list of all properties supported. If we take that route, here is a suggested list of such properties for tag: - rel - target - type - accesskey - class - style - title and for - alt - height - width What do you think about it? > The HTML exporter should produce valid HTML regardless of the input. We cannot remove the ability to shoot oneself in the foot. The HTML back-end cannot be responsible for undefined syntax. Think about: @@html:@@ > The Org manual describes ATTR_HTML as a feature that applies to the > following image or link. It makes no mention of restrictions to > following content in the paragraph, and neither does it say it will > apply to all following images or links. The manual could be amended to > say that ATTR_HTML applies to just the next image or link. To fit the > current situation, it might say, "In cases where ATTR_HTML is applied to > an image in a paragraph, following links will not be made invalid." But > why would anyone be expecting invalid HTML in the first place? > > Incidentally, I always thought that simply using another HTML_ATTR would > handle multiple images or links in the old exporter. In other words, > this: > > #+ATTR_HTML: width="10" alt=" [Cool thing] " > [[file:cool_thing.jpg]] > This is a paragraph about cool things. > #+ATTR_HTML: class="bar" > Cool thing found here [[http://example.com/][example.com]]. > > Would become this: > >

> [Cool thing] This is a > paragraph about cool things. Cool thing found here href="http://example.com/" class="bar">example.com. >

> > I don't remember using that in the old exporter, but I thought it would > work. > > It almost works in the new exporter, but it begins a new paragraph > before the second #+ATTR_HTML. I'm not sure this is the intended > behavior, though, because it isn't formatted like other new > paragraphs. This is the intended behaviour. Affiliated keywords can only exist at the beginning of the element they refer to. So, in the previous example, you start two paragraphs. > Alternatively, having ATTR_HTML (or something more general) apply to the > next thing, and having that work within paragraphs, is another > possibility. However, this may not fit within the limitations of the > new parser. Plus it's kind of ugly. The parser won't support it. It goes against the definition of an affiliated keyword. Moreover, it's merely a hack (what about links in tables?). And it's ugly, indeed. > Until there is a "proper" solution, however, could we please modify the > exporter to apply ATTR_HTML to only the next image or link? I am very > sure that was the spirit of the old exporter, and it would be nice if I > could maintain my documents in Org without resorting to (even more) > hacks. Done. Regards, -- Nicolas Goaziou