emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Christian Moe <mail@christianmoe.com>
To: Samuel Wales <samologist@gmail.com>, Org Mode <emacs-orgmode@gnu.org>
Subject: Re: ATTR_HTML for a clickable image, howto?
Date: Wed, 11 Apr 2012 10:11:57 +0200	[thread overview]
Message-ID: <4F853CCD.4020601@christianmoe.com> (raw)
In-Reply-To: <CAJcAo8vF5_oaHMokNQNA-f0y=DKbTMi-e3caDEj_8iZoMUFMCA@mail.gmail.com>

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	other threads:[~2012-04-11  8:11 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-01 21:27 ATTR_HTML for a clickable image, howto? François Pinard
2012-04-02  8:14 ` Bastien
2012-04-02 10:34   ` Christian Moe
2012-04-02 15:06     ` Bastien
2012-04-02 21:30       ` Samuel Wales
2012-04-03  5:42         ` Bastien
2012-04-05 23:34           ` Samuel Wales
2012-04-05 15:02   ` François Pinard
2012-04-06  8:52     ` Christian Moe
2012-04-06  9:29       ` Christian Moe
2012-04-06 18:41       ` Samuel Wales
2012-04-06 18:45         ` Samuel Wales
2012-04-07 13:15         ` Christian Moe
2012-04-10 23:53           ` Samuel Wales
2012-04-11  8:11             ` Christian Moe [this message]
2012-05-12  0:43               ` Samuel Wales
2012-05-20  1:00               ` Macros [was: Re: ATTR_HTML for a clickable image, howto?] François Pinard
2012-05-20  8:02                 ` Nicolas Goaziou
2012-05-20  8:34                   ` Yagnesh Raghava Yakkala
2012-05-20 10:24                     ` Nicolas Goaziou
2012-05-22 23:23                 ` Bastien
2012-07-05 14:40                 ` Bastien
2012-07-05 15:09                   ` Nicolas Goaziou
2012-07-05 15:51                     ` Sebastien Vauban
2012-07-05 20:44                       ` Nicolas Goaziou
2012-08-05  9:19                     ` Bastien
2012-05-20  0:39           ` ATTR_HTML for a clickable image, howto? François Pinard
2012-04-06  9:02     ` Bastien

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4F853CCD.4020601@christianmoe.com \
    --to=mail@christianmoe.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=samologist@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).