Re: Re: Org publish hierarchies and style variable

[Sebastian Rose <sebastian_rose@gmx.de>]

Richard Riley <rileyrgdev@googlemail.com> writes:
>> That's why I stick with the 'level-files' solution. This way it works
>> without any server-side scripting, postprocessing, networking and simply
>> on each and ervery host. Even when accessed through the file: protocol
>> localy. All I need is emacs and a webbrowser to browse my notes or test
>> publishing.
>
> I think cascading stylesheets using relative file notation provide the
> same benefit. Note "think" since its been a while since I implemented my
> org solution for my small web.


Yes, if all you use is stylesheet. I use paths in my setup for
org-info.js too, and you could add libraries (Perl, PHP....) or
something. Thanks to the level files, it's easy to move the file
around. Also, they provide 'view classes'. E.g., I can change a simple
file into a presentation by adding a few characters I remember, instead
of changing/adding all those lines of a export template.

Admittendly, I move files quite often. I split them in several files as
they grow, put those files into an extra directory and so on.


>> To do fancy stuff, we may use the either :style in
>> org-publish-projects-alist or the corresponding #+STYLE: file-variable
>> (e.g. in a level-file), to add arbitrary stuff to the head section. I'll
>> just use the #+STYLE: option for readability.
>
> You need to add it to each file if its a file specific style - that's
> fine.


Just make it the value of :style in org-publish-projects-alist.
#+STYLE: just overwrites that.


>> An other solution to use only one stylesheet, and be able to move files
>> around (not working through the file: protocol or without network, just
>> as Bernt's setup):
>>
>> #+STYLE: <base href="http://host.domain.tld" />
>
> Assuming it is a web specific style this is not necessary using cascades
> as I outlined and which also works with out "real host" testing. I can
> see this being possibly necessary when you want to borrow other peoples
> styles however.

No, not neccessary. Just one possibilty to have a stylesheet in the
document root, and use just one header for all files.

If you have http://host.domain.tld/main.css, all files may use

<base href="http://host.domain.tld" />
<link rel="stylesheet" type="text/css" href="main.css" />

regardless of position in the directory tree.

>>
>> If Php is supported on all hosts, you may use the next snippet, to make
>> it portable (publish on several hosts without changing anything):
>>
>> :#+STYLE: <?php
>> :#+STYLE: echo '<base href="http://' . $_SERVER['SERVER_NAME'] . '" />';
>> :#+STYLE: ?>
>>
>>
>> That way _all_ the URLs in stylesheets
>> (background-image:url(images/foo.gif)), image tags, hyperlinks etc. are
>> resolved relative to http://host.domain.tld.
>
> This has further ramifications I think. Namely including things
> relative. e.g sub dir in a web http:/web/proj1. Normally if I do not
> provide a full URL I want it relative. e.g "url:./images/proj1.jpg"


That's, what the base element is for. The nice part of it is, that all
_realtive_ paths are relative to the address basis (which makes them
abolute, yes), which means I don't have to change them, when I move the
file around.


It has indeed some disadvantages:

  - relative links will not work for the *.org files.
  - file: protocol does not work.


That's why I don't use it here. If I was to publish to a website, I
would take it in account. No need to change any image URL in the files,
when moving them from one directory to another.

/Normal/ links _to_ the file will always stop working, when moving a
file. That's one of the reasons, why we use databases instead of plain
HTML files for real web sites. However, the relative links _from_ the
moved file to others will still work, if you supply a address basis.



Best,

-- 
Sebastian Rose, EMMA STIL - mediendesign, Niemeyerstr.6, 30449 Hannover

Tel.:  +49 (0)511 - 36 58 472
Fax:   +49 (0)1805 - 233633 - 11044
mobil: +49 (0)173 - 83 93 417
Http:  www.emma-stil.de