>>I've been thinking that perhaps we should define ":url(...)" as a
lazy form of [=...=]
That would be helpful (though somewhat specialized from your point of
view I imagine).
In the meantime I've remembered my workaround (from about a year ago):
$FarmPubDirUrl = '/shared/wiki/app/pub';
$PubDirUrl = '/wiki/pub'; #prevent unwanted conversion to full url in
style url(.. strings
#$FarmPubDirUrl =
$UrlScheme.'://'.$_SERVER['HTTP_HOST'].'/shared/wiki/app/pub';
#$PubDirUrl = $UrlScheme.'://'.$_SERVER['HTTP_HOST'].'/wiki/pub';
IOW if I use relative directory addressing for PubDirUrl and
FarmPubDirUrl (from which SkinDirUrl is derived) then the url(...
substitution takes place correctly. I presume presence of the $UrlScheme
is triggering the image element string substitution. However would this
use of relative addressing be a problem for https:// sites?
Thanks,
- Henrik
(Incidentally /shared/wiki/ is a symlink into the shared farm environment)
Patrick R. Michaud wrote:
On Mon, Feb 09, 2009 at 08:09:04PM -0500, Henrik Bechmann wrote:
All,
I have the following markup:
(:div2 class="header-content"
style="height:84px;background-image:url({$SkinDirUrl}/garden_bg.jpg);":)
(I've added background-image to the $WikiStyleCSS[] array)
But PmWiki is parsing the image fragment as an element, and creates an
embedded image element thus:
background-image:url(<img
src='http://parkcommons.ca/shared/wiki/app/pub/skins/FoldersCMSBase/garden_bg.jpg'
alt='' title='' />)
...which of course is a css error.
I've been thinking that perhaps we should define ":url(...)"
as a lazy form of [=...=] that protects its contents from
being treated as a link. Then the above would work.
Pm
--
Henrik Bechmann
bechmann.ca
_______________________________________________
pmwiki-users mailing list
[email protected]
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
