From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christian Moe Subject: Re: ATTR_HTML for a clickable image, howto? Date: Wed, 11 Apr 2012 10:11:57 +0200 Message-ID: <4F853CCD.4020601@christianmoe.com> References: <86pqbrywgr.fsf@iro.umontreal.ca> <87r4w63602.fsf@gnu.org> <86vclekyqo.fsf@iro.umontreal.ca> <4F7EAED9.2040804@christianmoe.com> <4F803DDC.20808@christianmoe.com> 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]:50499) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SHseB-00063S-Mj for emacs-orgmode@gnu.org; Wed, 11 Apr 2012 04:11:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SHse5-0007hX-AG for emacs-orgmode@gnu.org; Wed, 11 Apr 2012 04:11:23 -0400 Received: from b1.hitrost.net ([91.185.211.67]:49255) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SHse5-0007dg-0H for emacs-orgmode@gnu.org; Wed, 11 Apr 2012 04:11:17 -0400 In-Reply-To: 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: Samuel Wales , Org Mode Hi again, On 4/11/12 1:53 AM, Samuel Wales 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. Are those two separate questions, perhaps? I tried with org-export-as-region, and I still got the full HEAD section. So the solutions I posted to François should still work with that function. However, they would not work when the exported HTML is stripped of the HEAD section. > > 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. No doubt there's some way you could wrap everything inside the section in a
, but any CSS in its STYLE attribute would apply to that div element as a whole, i.e. to all the contents, not selectively to bits and parts inside it. That's probably not what you want. > > 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. Maybe it's the wrong goal. :-) But if that's what you want to do, the current options for doing local STYLE= formatting that I can think of are the same as for setting classes or ids: 1. #+attr_html on some elements, and 2. verbatim HTML with #+HTML or with the `@' notation; repeated use of which could be simplified with (a mix of) 3. macros; 4. org-exp-blocks.el; 5. custom link types (didn't mention that yet, see: http://orgmode.org/worg/org-tutorials/org-latex-export.html#sec-10-3); or even 6. Babel src and call commands (very exotic for the purpose of formatting a bit of html). Beyond that, we'd need something like the extensible syntax you have proposed previously. Personally, I'm looking forward to Nicolas Gouaziou's exporter, which I believe will handle ATTR commands in a more systematic way. >> (...) Then these solutions won't >> work without modifying CSS in your CMS. > > Not even with wrapping the entire output in a div? I don't think so. >> 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. OK. Even so, though, the CMS will probably apply its own stylesheet by default, and there's a small but non-zero chance it will interact with your local formatting in ways you don't want; e.g., the orange text background you specify clashes horribly with off-peach surroundings... So you may end up having to edit stylesheets anyway. >> - 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. Not quite sure what you have in mind, but I don't think so. >> - 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. No, not if you can't or won't control what stylesheets will be applied. >> [...] >> - You can simplify repeated use with macros. [...] > For paragraphs and sections and quotes and so on, the #+ blocks would > work better. Not sure if {{{}}} would nest? Yes, macros will nest. (As opposed to custom links.) E.g.: #+MACRO: mycolor @$1@ #+MACRO: blue @$1@ #+MACRO: red @$1@ {{{mycolor(This is a single paragraph where I'd like text on an orange background\, {{{blue(except where I want a blue blackground and some {{{red(red)}}} in between)}}}.)}}} > 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 may be right. I have had success adding a block-level element (DIV) with a macro, but I had to take special care to close the preceding P tag to get valid xhtml. That's why in the example I gave, I used the macro to wrap the whole text content of the block in a SPAN, rather than a DIV. There are other drawbacks, such as needing to backslash-escape any commas (as in the above example). And extensive use of macros looks terribly messy in Org source, though the same is likely true for any other extensive use of means to local formatting. Yours, Christian