From mboxrd@z Thu Jan 1 00:00:00 1970 From: Samuel Wales Subject: Re: ATTR_HTML for a clickable image, howto? Date: Tue, 10 Apr 2012 16:53:43 -0700 Message-ID: References: <86pqbrywgr.fsf@iro.umontreal.ca> <87r4w63602.fsf@gnu.org> <86vclekyqo.fsf@iro.umontreal.ca> <4F7EAED9.2040804@christianmoe.com> <4F803DDC.20808@christianmoe.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Return-path: Received: from eggs.gnu.org ([208.118.235.92]:53028) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SHl0X-0007aA-Nk for emacs-orgmode@gnu.org; Tue, 10 Apr 2012 20:01:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SHl0V-00086I-BY for emacs-orgmode@gnu.org; Tue, 10 Apr 2012 20:01:57 -0400 Received: from mail-iy0-f169.google.com ([209.85.210.169]:42443) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SHksb-0005Yg-HV for emacs-orgmode@gnu.org; Tue, 10 Apr 2012 19:53:45 -0400 Received: by mail-iy0-f169.google.com with SMTP id r24so541805iaj.0 for ; Tue, 10 Apr 2012 16:53:43 -0700 (PDT) In-Reply-To: <4F803DDC.20808@christianmoe.com> 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: mail@christianmoe.com Cc: =?UTF-8?Q?Fran=C3=A7ois_Pinard?= , emacs-orgmode@gnu.org Hi Christian, Thanks for your reply. I left implicit the question of whether this can solve OP's problem also, but believe it is potentially related. However, if I understood CSS well enough to ask the question precisely, I'd have the answer. So bear with me. More below: On 2012-04-07, Christian Moe wrote: >> Will CSS solutions described in this thread work if you always export >> subtrees (not entire .org files) and never include style files? > > Yes, CSS styles apply to exported subtrees as well, whether from the > default stylesheet, linked external stylesheets, or #+STYLE headers. Hmm, I think I should have specified further. I mean org-export-region-as-html. The raw HTML without any head section, files, stylesheets, or anything else. So for example, could the OP and I use styles that are specified with div style= wrapping the entire output? Seems a simple addition to the exporter or even a defadvice, but I don't know if it would work as I don't know what the CSS would look like well enough to try it. The critical thing is to avoid all dependency on anything external like a stylesheet. The goal is to keep all information in your file under Org control, including style. > But this applies to the static html files as exported by Org. If I > understand your drift, you're thinking about using it in a content > management system (CMS) like Blogger. A CMS will typically store only > the content of your document and substitute its own template for the > HEAD section where style information goes. Then these solutions won't > work without modifying CSS in your CMS. Not even with wrapping the entire output in a div? > You can edit the CSS template of your CMS to take advantage of the > classes and ids Org applies to its HTML exports. The idea is to avoid a dependency like that if possible. > - You can use #+ATTR_HTML to add class, id or style attributes to > /some/ elements, and my understanding is that the new exporter that is > in the works will help do this more systematically. Wondering if you can control this under my additional requirements using inheritance from higher-level constructs like a div wrapper around the whole export. > - You can enclose blocks in custom block classes (
) > with org-special-blocks (#+BEGIN_FOO), or with verbatim HTML. Yes, this is where I was leading. But it's no good for my purposes if you can't use CSS directly in your Org file without any header or external files. > Locally applying CSS to elements with the STYLE attribute, the very > lowest level of the cascade, should be the last resort. Right. :) > - You can simplify repeated use with macros. See the manual, section > 11.6. Use the @ notation (section 12.5.3) for literal html tags within > the macros. E.g.: > > #+MACRO: mycolor @$1@ I've tried macros for image specification, but ran into a variety of issues getting it to work well. > {{{mycolor(Here I'd like some black text on an orange background.)}}} For paragraphs and sections and quotes and so on, the #+ blocks would work better. Not sure if {{{}}} would nest? Or be noticeable. That seems much better for spans of text, not so much for standalone images and sections with more than one paragraph, lists, etc. > - You could probably also use Eric Schulte's contributed > org-exp-blocks.el, but you'd need to write some code, and it might be > overkill for this purpose. I was wondering if this would be useful too. > Depends on your use case, I guess, but I think it would nearly always > be a better, simpler, cleaner solution to modify your Blogger CSS. OK. But my desire not to depend on the cloud is large enough that I have to go back to the raw HTML method. I want this to work no matter who I give the HTML file (singular) to. Assuming it's possible -- if not I will just keep using raw HTML. This is not a critical issue, but I thought it could expand the OP's conversation to include a general solution for everybody if it works. Samuel -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com