From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christian Moe Subject: Re: ATTR_HTML for a clickable image, howto? Date: Fri, 06 Apr 2012 10:52:41 +0200 Message-ID: <4F7EAED9.2040804@christianmoe.com> References: <86pqbrywgr.fsf@iro.umontreal.ca> <87r4w63602.fsf@gnu.org> <86vclekyqo.fsf@iro.umontreal.ca> Reply-To: mail@christianmoe.com Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([208.118.235.92]:48358) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SG4uD-0004Oq-Rc for emacs-orgmode@gnu.org; Fri, 06 Apr 2012 04:52:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SG4u9-0000YI-1u for emacs-orgmode@gnu.org; Fri, 06 Apr 2012 04:52:29 -0400 In-Reply-To: <86vclekyqo.fsf@iro.umontreal.ca> 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: =?UTF-8?B?RnJhbsOnb2lzIFBpbmFyZA==?= Cc: emacs-orgmode@gnu.org Hi, On 4/5/12 5:02 PM, François Pinard wrote: > I understand what you mean by saying it does not make sense with the > current mechanics. Yet, from a user perspective, it surely makes sense > hoping that Org offers a way for adding attributes to either part of a > link, as links are kind of indivisible (so far that I know). On reflection, there might be a case for making the exporter smart enough not to place #+ATTR_HTML attributes such as ALT, WIDTH and HEIGHT (or even ALIGN, though see below) in the element, where they have no place, but instead pass them through to the clickable image, where they obviously belong. >> I suggest you fix your css instead. > > My knowledge of CSS is rudimentary. I'm not aware that CSS (the version > widely available, not the incoming one) has enough matching capabilities > to spot wrong HTML, remove attributes on some elements and add them on > other elements. Is that really possible? Should I dive and study CSS > more? Without matching, CSS would not help much, as the correction is > needed in three dozen cases at most, and not blindly for all images. No, CSS doesn't move attributes around. But the ALIGN attribute has long been deprecated in favor of CSS. All the CSS needed to right-align all images that are children of a link anchor is: a img {float: right;} (There are other, more complex ways to control horizontal alignment in CSS.) To set this on a per-document basis in Org, use: #+STYLE: If you need more fine-grained control, you could use e.g.: a.rightaligned img {float: right;} where "rightaligned" is an arbitrary name, you could call the class "alignright" or "right" or "rt" or whatever. Then you could set the "rightaligned" class on all links you want right-aligned: #+ATTR_HTML: class="rightaligned" [[./targetimage.png][./linkimage.png]] Note that it's still the element that gets the class. In this case, the CSS applies to all child elements of elements. For this particular purpose, though, that CSS may be overkill; looks to me like you get the same visual result by just styling directly. So here's the whole CSS for right-aligning any block element on which you can set the CLASS to "rightaligned" with ATTR_HTML: .rightaligned {float: right;} > I could ponder using XSL or something else to post-process the HTML > generated by Org, so circumventing the limitation. This would be adding > an unwelcome layer of complexity. I like to perceive Org as a tool > which much simplify my life! :-). Any problem you can solve with a single line of simple CSS, you can probably solve with a deprecated tag, several lines of complicated XSL, and a postprocessing hook in Org to issue a shell command to an XSLT processor... But why would you? If you like Org for its simplicity, you will love CSS. Yours, Christian