emacs-orgmode
[Top][All Lists]
Advanced
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] ATTR_HTML for a clickable image, howto?

From: Christian Moe
Subject: Re: [O] ATTR_HTML for a clickable image, howto?
Date: Wed, 11 Apr 2012 10:11:57 +0200
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 
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 <BODY> section in a <DIV>, 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 (<DIV CLASS="foo">)
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 @<span style="background-color: #f4a460">$1@</span>
#+MACRO: blue @<span style="background-color: blue">$1@</span>
#+MACRO: red @<span style="background-color: red">$1@</span>

{{{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
reply via email to
[Prev in Thread] Current Thread [Next in Thread]