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 15:03:22 +0100 Message-ID: <87liacfq39.fsf@gmail.com> References: <87fw0nibde.fsf@gmail.com> <871uc4acid.fsf@lapcat.tftorrey.com> <87vc9gfqr3.fsf@gmail.com> <87ECBE135E874829AB4A580F87BD3EB2@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([208.118.235.92]:36905) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U9yeb-0002gr-LK for emacs-orgmode@gnu.org; Mon, 25 Feb 2013 09:03:46 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U9yeW-0000Nt-LI for emacs-orgmode@gnu.org; Mon, 25 Feb 2013 09:03:41 -0500 Received: from mail-wg0-f45.google.com ([74.125.82.45]:57024) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U9yeW-0000Nj-FJ for emacs-orgmode@gnu.org; Mon, 25 Feb 2013 09:03:36 -0500 Received: by mail-wg0-f45.google.com with SMTP id dq12so2503733wgb.24 for ; Mon, 25 Feb 2013 06:03:35 -0800 (PST) In-Reply-To: <87ECBE135E874829AB4A580F87BD3EB2@gmail.com> (Vincent Beffara's message of "Mon, 25 Feb 2013 14:57:23 +0100") 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: Vincent Beffara Cc: emacs-orgmode@gnu.org Hello, Vincent Beffara writes: >> #+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 ? A generic :options keyword is a good idea, indeed. But we still have to agree on the common options part. For example, I think :id is dangerous, because Org already provides its own way to generate these properties (e.g. through #+NAME: keywords). If we make a list of such options, per tag type, I can try to implement it. Anyone wants to start? Regards, -- Nicolas Goaziou