From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vincent Beffara Subject: Re: Bug: New HTML exporter incorrect attributes Date: Mon, 25 Feb 2013 14:57:23 +0100 Message-ID: <87ECBE135E874829AB4A580F87BD3EB2@gmail.com> References: <87fw0nibde.fsf@gmail.com> <871uc4acid.fsf@lapcat.tftorrey.com> <87vc9gfqr3.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Return-path: Received: from eggs.gnu.org ([208.118.235.92]:34020) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U9yYq-0000LD-DA for emacs-orgmode@gnu.org; Mon, 25 Feb 2013 08:58:00 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U9yYY-0006l1-TY for emacs-orgmode@gnu.org; Mon, 25 Feb 2013 08:57:44 -0500 Received: from mail-wg0-f45.google.com ([74.125.82.45]:59709) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U9yYY-0006kF-Ib for emacs-orgmode@gnu.org; Mon, 25 Feb 2013 08:57:26 -0500 Received: by mail-wg0-f45.google.com with SMTP id dq12so2384356wgb.0 for ; Mon, 25 Feb 2013 05:57:24 -0800 (PST) In-Reply-To: <87vc9gfqr3.fsf@gmail.com> Content-Disposition: inline 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: Nicolas Goaziou Cc: emacs-orgmode@gnu.org > #+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. How about both? I.e. a short-list of common options (class, title, id for links typically) plus a generic "options" as a back up to put whatever is not in the short-list ? /v, big fan of the ugliest solutions imaginable > 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 (http://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