, 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