Org publish hierarchies and style variable

Org publish hierarchies and style variable

[mdl]

A question: The org-publish tutorial recommends the use of template
files for setting the relative link to the stylesheet for nested
directories to be published to html.
 
- http://orgmode.org/worg/org-tutorials/org-publish-html-tutorial.php

E.g., 

For first level directories such as 

  ~/org/
      |- css/
      |  |- stylesheet.css
      |- index.org
      |- Emacs
      |   |- index.org 
                         
~/org/Emacs/index.org would contain the following:

#+SETUPFILE: ~/.emacs.d/level-1.org

which points to a setupfile with the option:

#+STYLE: <link rel="stylesheet" type="text/css"\
         href="../stylesheet.css" />

My question: Instead of this method, which I find a little tedious,
I've created a hardlink to the master css directory in each
subdirectory of my project. As a result the, css files get copied to
each subdirectory in my public web directory and I only need to
specify a single style option in my org-publish-alist.

Apart from taking up extra disk space on the server (and thus being
less economical), are there any other potential problems with this
approach? I'm using org as a wiki and have a lot of org files in each
subdirectory. This approach seems easier than having to add and tweak
the SETUPFILE option for each new org file. 

---
Matt Lundin
mdl at imapmail dot org

Re: Org publish hierarchies and style variable

[Bernt Hansen]

mdl@imapmail.org writes:

> A question: The org-publish tutorial recommends the use of template
> files for setting the relative link to the stylesheet for nested
> directories to be published to html.
>  
> - http://orgmode.org/worg/org-tutorials/org-publish-html-tutorial.php
>
> E.g., 
>
> For first level directories such as 
>
>   ~/org/
>       |- css/
>       |  |- stylesheet.css
>       |- index.org
>       |- Emacs
>       |   |- index.org 
>                          
> ~/org/Emacs/index.org would contain the following:
>
> #+SETUPFILE: ~/.emacs.d/level-1.org
>
> which points to a setupfile with the option:
>
> #+STYLE: <link rel="stylesheet" type="text/css"\
>          href="../stylesheet.css" />
>
> My question: Instead of this method, which I find a little tedious,
> I've created a hardlink to the master css directory in each
> subdirectory of my project. As a result the, css files get copied to
> each subdirectory in my public web directory and I only need to
> specify a single style option in my org-publish-alist.
>
> Apart from taking up extra disk space on the server (and thus being
> less economical), are there any other potential problems with this
> approach? I'm using org as a wiki and have a lot of org files in each
> subdirectory. This approach seems easier than having to add and tweak
> the SETUPFILE option for each new org file. 

I have lots of org files generating documents (some public, most not) at
http://doc.norang.ca/

,----
| Most of the public documents in doc.norang.ca have outdated
| information but the 'How to use git' document might be of interest to
| people on this mailing list.
`----

I wrote a simple Python CGI script that picks up any HTML file in that
directory and displays it on the index page.  Each page uses the same
CSS file.

I have one entry for CSS which I share between all of my pages:

,----[ part of my org-publish-project-alist ]
|  ("doc-org" :base-directory "~/git/doc.norang.ca/" :publishing-directory "/ssh:www-data@www:~/doc.norang.ca/htdocs" :recursive t :section_numbers nil :table-of-contents nil :base-extension "org" :publishing-function org-publish-org-to-html :style "<link rel=\"stylesheet\"\n                  href=\"/org.css\"\n                  type=\"text/css\">" :author-info nil :creator-info nil)
|  ("doc-css" :base-directory "~/git/doc.norang.ca/" :publishing-directory "/ssh:www-data@www:~/doc.norang.ca/htdocs" :base-extension "css" :publishing-function org-publish-attachment :recursive t :author nil)
|  ("doc" :components
|   ("doc-org" "doc-css"))
`----

I create docs in subdirectories under http://doc.norang.ca/ and each
document uses the css file in the root directory.  All the documents use
the same CSS file and therefore look the same.  You could of course
specify a fixed address for the stylesheet - there's no requirement to
use relative addressing for your stylesheets at all (i.e. I could have
replaced "/org.css" with "http://doc.norang.ca/org.css" and I'm free to
use that stylesheet for any page (even stuff not in the doc.norang.ca
domain)

Feel free to steal it if you like it :)

Maybe some of that is useful...

-Bernt

Re: Org publish hierarchies and style variable

[Sebastian Rose]

Hi Matt,


I can see no problem with the alternative you provide here. It's nice
IMHO. How  much space will a stylesheet take? One block, sometimes 2 -
not very much. Thanks for pointing this out.

There is the per file

#+STYLE:

setting.


We should mention those alternatives in the tutorial.



* Why I recommended the #+SETUPFILE option in the tutorial

  When moving files around, not only the path to the stylesheet is
  affected, but also paths to scripts, or PHP/Perl/whatever libraries
  and includes (which may live in the #+TEXT: line of a level file).

  I have 106 files and directories currently, constantly growing. And
  the head of the all the files just looks like this:

#+SETUPFILE: ~/emacs/org/levels/level-1.org
#+TITLE: Some Title

  Moving the file, just means to change one character (`1'), and the
  scripts, stylesheets, and all the rest still works.

  I use 6 level files for 3 levels (more to come):

  - 1 for startpage (No `Up' link, `Home' leads to my local homepage),
  - 2 for directory indexes (where `Up' means go to '../index.html',
    `Home' to my `sitemap.html'),
  - 3 for all the other files (where `Up' goes to 'index.html',
    `Home' to my `sitemap.html').


  Images in stylesheets ('background-image:url(.....)') are resolved
  realtive to the stylesheets location.




We should be able to add a '<base href="">' line ;-)



Regards,

   Sebastian


mdl@imapmail.org writes:
> A question: The org-publish tutorial recommends the use of template
> files for setting the relative link to the stylesheet for nested
> directories to be published to html.
>
> - http://orgmode.org/worg/org-tutorials/org-publish-html-tutorial.php
>
> E.g.,
>
> For first level directories such as
>
>   ~/org/
>       |- css/
>       |  |- stylesheet.css
>       |- index.org
>       |- Emacs
>       |   |- index.org
>
> ~/org/Emacs/index.org would contain the following:
>
> #+SETUPFILE: ~/.emacs.d/level-1.org
>
> which points to a setupfile with the option:
>
> #+STYLE: <link rel="stylesheet" type="text/css"\
>          href="../stylesheet.css" />
>
> My question: Instead of this method, which I find a little tedious,
> I've created a hardlink to the master css directory in each
> subdirectory of my project. As a result the, css files get copied to
> each subdirectory in my public web directory and I only need to
> specify a single style option in my org-publish-alist.
>
> Apart from taking up extra disk space on the server (and thus being
> less economical), are there any other potential problems with this
> approach? I'm using org as a wiki and have a lot of org files in each
> subdirectory. This approach seems easier than having to add and tweak
> the SETUPFILE option for each new org file.

--
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

Re: Org publish hierarchies and style variable

[Sebastian Rose]

Hi Matt,


The path problem could be addressed in a nice way:


#+STYLE: <base href="/" />


We may have several #+STYLE: lines, so we can add whatever we want to
the <head> section:


#+STYLE: <base href="/" />
#+STYLE: <?php require("some/code.php"); ?>
#+STYLE: <script type="text/javascript" language="JavaScript" src="jquery.js"></script>


The '<base href="" />' is _very_ interesting, all paths to
stylesheets, images (plus images in stylesheets!), flash films, applets
and scripts are resolved relative to this path by the browser!

This way, neither #+SETUPFILEs nor hard links are needed.





We could reuse the #+STYLE: option for everything related to HTML
export.

This would be easier on the maintainer (Carsten by now) then
adding an option for each and every feature we will request for HTML
publishing in the future.


Why didn't I think of it earlier???




Regards,

  Sebastian







mdl@imapmail.org writes:
> A question: The org-publish tutorial recommends the use of template
> files for setting the relative link to the stylesheet for nested
> directories to be published to html.
>  
> - http://orgmode.org/worg/org-tutorials/org-publish-html-tutorial.php
>
> E.g., 
>
> For first level directories such as 
>
>   ~/org/
>       |- css/
>       |  |- stylesheet.css
>       |- index.org
>       |- Emacs
>       |   |- index.org 
>                          
> ~/org/Emacs/index.org would contain the following:
>
> #+SETUPFILE: ~/.emacs.d/level-1.org
>
> which points to a setupfile with the option:
>
> #+STYLE: <link rel="stylesheet" type="text/css"\
>          href="../stylesheet.css" />
>
> My question: Instead of this method, which I find a little tedious,
> I've created a hardlink to the master css directory in each
> subdirectory of my project. As a result the, css files get copied to
> each subdirectory in my public web directory and I only need to
> specify a single style option in my org-publish-alist.
>
> Apart from taking up extra disk space on the server (and thus being
> less economical), are there any other potential problems with this
> approach? I'm using org as a wiki and have a lot of org files in each
> subdirectory. This approach seems easier than having to add and tweak
> the SETUPFILE option for each new org file. 
>
> ---
> Matt Lundin
> mdl at imapmail dot org
>
>
>
> _______________________________________________
> Emacs-orgmode mailing list
> Remember: use `Reply All' to send replies to the list.
> Emacs-orgmode@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode
>

-- 
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
Email: s.rose emma-stil de, sebastian_rose gmx de
Http:  www.emma-stil.de

Re: Org publish hierarchies and style variable

[Matthew Lundin]

Bernt,

Bernt Hansen <bernt@norang.ca> writes:

> mdl@imapmail.org writes:
...
>> My question: Instead of this method, which I find a little tedious,
>> I've created a hardlink to the master css directory in each
>> subdirectory of my project. As a result the, css files get copied to
>> each subdirectory in my public web directory and I only need to
>> specify a single style option in my org-publish-alist.
... 
>
> I create docs in subdirectories under http://doc.norang.ca/ and each
> document uses the css file in the root directory.  All the documents use
> the same CSS file and therefore look the same.  You could of course
> specify a fixed address for the stylesheet - there's no requirement to
> use relative addressing for your stylesheets at all (i.e. I could have
> replaced "/org.css" with "http://doc.norang.ca/org.css" and I'm free to
> use that stylesheet for any page (even stuff not in the doc.norang.ca
> domain)

Thanks for this very simple solution. 

Best,

Matt

Re: Org publish hierarchies and style variable

[Richard Riley]

Matthew Lundin <mdl@imapmail.org> writes:

> Bernt,
>
> Bernt Hansen <bernt@norang.ca> writes:
>
>> mdl@imapmail.org writes:
> ...
>>> My question: Instead of this method, which I find a little tedious,
>>> I've created a hardlink to the master css directory in each
>>> subdirectory of my project. As a result the, css files get copied to
>>> each subdirectory in my public web directory and I only need to
>>> specify a single style option in my org-publish-alist.
> ... 
>>
>> I create docs in subdirectories under http://doc.norang.ca/ and each
>> document uses the css file in the root directory.  All the documents use
>> the same CSS file and therefore look the same.  You could of course
>> specify a fixed address for the stylesheet - there's no requirement to
>> use relative addressing for your stylesheets at all (i.e. I could have
>> replaced "/org.css" with "http://doc.norang.ca/org.css" and I'm free to
>> use that stylesheet for any page (even stuff not in the doc.norang.ca
>> domain)
>
> Thanks for this very simple solution. 
>
> Best,
>
> Matt
>
>
> _______________________________________________
> Emacs-orgmode mailing list
> Remember: use `Reply All' to send replies to the list.
> Emacs-orgmode@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode
>

I dont know if this is appropriate or how late I came into this
discussion but I publish a web thats a few directories deep and I simply
have a dummy style at each level which cascades back to the master.

Something like

,---- style.css
| @import url(../style.css);
`----

combined with:

,----
| 	("web-org"
| 	 :base-directory "~/webs/rgr/"
| 	 :publishing-directory "/ssh:rgrweb:/home/shamrock/rgrweb/"
| 	 :base-extension "org"
| 	 :publishing-function org-publish-org-to-html
|          :recursive t
| 	 :section-numbers nil
| 	 :style "<link rel=stylesheet
|                      href=\"./style.css\"
|                      type=\"text/css\">"
| 	 :auto-preamble t
| 	 :auto-postamble t
| 	 :preamble "<div id='Content'><a href='../'>Back</a> - <a href='http://rgrweb/default/'>Home</a>"
| 	 :postamble "</div>"
| 	 :author nil
| 	 )
| 
`----

in my org-publish-project-alist

I don't know if things have barreled  along so quickly that this is more
patching and sticking plaster than a solid solution but it works well for
me.


regards

richard.


-- 
 important and urgent problems of the technology of today are no longer the satisfactions of the primary needs or of archetypal wishes, but the reparation of the evils and damages by the technology of yesterday.  ~Dennis Gabor, Innovations:  Scientific, Technological and Social, 1970

Re: Re: Org publish hierarchies and style variable

[Richard Riley]

Sebastian Rose <sebastian_rose@gmx.de> writes:

> Richard Riley <rileyrgdev@gmail.com> writes:
>> I don't know if things have barreled  along so quickly that this is more
>> patching and sticking plaster than a solid solution but it works well for
>> me.
>
> That's the important thing: it has to work for you ;-)
>
> 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.
>
> But it is indeed tailored to my needs: note-taking.
>
> 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. But that can mix with the cascaded style method I suggested. The
benefit of the simple method I outlined is that you still (or already)
also have a specific style sheet for the project level or directory
too. A good place to add sub web specific look and feel should you want.

>
>
> 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.

>
> 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"

>
>
> See http://www.w3.org/TR/REC-html40/struct/links.html#h-12.4 for details how
> links are resolved when using the base element (HTML 4.0 is the basis for
> XHTML 1.0 strict).
>
>
>
> Regards,
>
>    Sebastian

-- 
 important and urgent problems of the technology of today are no longer the satisfactions of the primary needs or of archetypal wishes, but the reparation of the evils and damages by the technology of yesterday.  ~Dennis Gabor, Innovations:  Scientific, Technological and Social, 1970

Re: Re: Org publish hierarchies and style variable

[Sebastian Rose]

Richard Riley <rileyrgdev@gmail.com> writes:
> I don't know if things have barreled  along so quickly that this is more
> patching and sticking plaster than a solid solution but it works well for
> me.

That's the important thing: it has to work for you ;-)

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.

But it is indeed tailored to my needs: note-taking.

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.


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" />


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.


See http://www.w3.org/TR/REC-html40/struct/links.html#h-12.4 for details how
links are resolved when using the base element (HTML 4.0 is the basis for
XHTML 1.0 strict).



Regards,

   Sebastian


-- 
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

Re: Re: Org publish hierarchies and style variable

[Richard Riley]

Sebastian Rose <sebastian_rose@gmx.de> writes:

> 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

My comments are limited to Stylesheets at present.

> 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.

I think you have lost me here. The cascaded method does have level
files. At a default they simply cascade to the one above if it exists.

And the relative cascade works with all protocols. Possibly we are
agreeing. Since I do not understand what you mean above when you talk
about adding/changing lots of lines or adding a few characters to a
presentation. Do you mean adding some style info?

>
> 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.

Yes : file specific as I mentioned above should you want it.  With my
way you can have the basic cascade and the file specifics I think. 

>
>
>>> 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.

One header for all the files? Yes. But this can still use cascaded
styles.

>
> 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.

Of course : hard coded to a single style. A more flexible, I feel,
approach is to use the cascaded styles and have root style include that
host specific one.

>
>>>
>>> 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.

And thus means the example I gave above is broken. I think I don't like
setting the base href to be honest. It tend to think of it as less
flexible. Sure SOME individual files might want to do this but to set
this up as part of the project definition is losing flexibility and
localization as I outlined above with my proj1 example.
>
>
> It has indeed some disadvantages:
>
>   - relative links will not work for the *.org files.
>   - file: protocol does not work.

And this is a major disadvantage. And one not met with relative cascades.
>
>
> 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.

I'm not sure I understand your meaning here. Moving image files around?
Basically you seem to be advocating hard coded locations as opposed to
project local locations-

>
> /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,

-- 
 important and urgent problems of the technology of today are no longer the satisfactions of the primary needs or of archetypal wishes, but the reparation of the evils and damages by the technology of yesterday.  ~Dennis Gabor, Innovations:  Scientific, Technological and Social, 1970

Re: Re: Org publish hierarchies and style variable

[Sebastian Rose]

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