Andrew Pollack's Blog
Technology, Family, Entertainment, Politics, and Random Noise| Professional Services | Second Signal | Presentations | Andrew's Blog | Support |
File this under "Damn, I should have known that" -- CSS and Relative Paths
By Andrew Pollack on 03/18/2010 at 07:33 AM EDTI was whining about a feature being missing in Designer 8.5.x yesterday in a closed forum for "Design Partners" when I learned something I wished I'd known a long time ago. I'm writing this to share it with you, so you can be saved the work I've been doing.
The feature I wanted (and still want) is for file resources that use the new editors (e.g. CSS, HTML, JAVASCRIPT) to allow "<computed text>" values or at least some form of tokenization to allow you to include things like "@webdbname" and profile document values in your CSS or Javascript files Without such a feature I've had to create "page" elements instead without the snazzy editors.
I was describing the problem in context of CSS pages and paths to image resources stored in the same database, when Nathan made a comment that it just seems to work fine for him. So, of course first I declared that I was more than 99% sure that was impossible, but then (giving the man his due) I decided to research it. Of course, I learned something I should have known.
If you look at the CSS Spec ( http://www.w3.org/TR/REC-CSS1/ ) section 6.4 clearly states
Partial URLs are interpreted relative to the source of the style sheet, not relative to the document:..
So, what that means in a Domino database is that if you have a file resource, it is always accessed relative to the top of the NSF (e.g. ../../mydatabase.nsf/myImage.jpg ) and your CSS file is the same (e.g. ../../mydatabase.nsf/mystyle.css ). Even if the document you're loading the css from is in a different database, or in a view or document buried down somewhere inside that database, as long as the images referenced in the css URL() statements are in the same database as the CSS file itself, they'll be seen and loaded correctly without having to specify the full path to the images.
In other words, if you have mystyle.css as a file resource in mydatabase.nsf, and it contains this statement:
div.myFancyDiv { background-image:url(mybackground.jpg) ; }
It will work even if you are calling to /mydatabase.nsf/mystyle.css from another database, another server, a view nested deeper in the same database, or anywhere else.
When I think of how many wasted hours I've spent.....ugh.
re: File this under "Damn, I should have known that" -- CSS and Relative PathsBy Nathan T. Freeman on 03/18/2010 at 08:25 AM EDT
re: File this under "Damn, I should have known that" -- CSS and Relative PathsBy Charles Robinson on 03/18/2010 at 10:02 AM EDT
When I played around with Domino web apps a few years ago (6.x) I stumbled
across this functionality. I read the CSS spec and just assumed everyone else
already knew about it, and I didn't because I was a newbie. :-)
across this functionality. I read the CSS spec and just assumed everyone else
already knew about it, and I didn't because I was a newbie. :-)
re: File this under "Damn, I should have known that" -- CSS and Relative PathsBy Bruce Lill on 03/18/2010 at 11:30 AM EDT
It's relative to the last "/" which may or may not be the filename. If you set
an xpage to the launched at start-up it will point to the path not the nsf >>
web/home.nsf has h.xsp as start-up page will have a relative path of web/ but
web/home.nsf/h.xsp will work.
I see this when developers also put the css in the HTML of the form/page
instead of as a CSS file.
Always test in a sub-folder.
an xpage to the launched at start-up it will point to the path not the nsf >>
web/home.nsf has h.xsp as start-up page will have a relative path of web/ but
web/home.nsf/h.xsp will work.
I see this when developers also put the css in the HTML of the form/page
instead of as a CSS file.
Always test in a sub-folder.
re: File this under "Damn, I should have known that" -- CSS and Relative PathsBy Andrew Pollack on 03/18/2010 at 11:49 AM EDT
that depends. If the xpage calls out to an external css file, then it's the
last / (the realm) that the CSS file resides in, not the xpage -- at that
point, the xpage's location has no relationship to the relative path of the
objects referenced in the external css file.
last / (the realm) that the CSS file resides in, not the xpage -- at that
point, the xpage's location has no relationship to the relative path of the
objects referenced in the external css file.
Other Recent Stories...
- 01/26/2023Better Running VirtualBox or VMWARE Virtual Machines on Windows 10+ Forgive me, Reader, for I have sinned. I has been nearly 3 years since my last blog entry. The truth is, I haven't had much to say that was worthy of more than a basic social media post -- until today. For my current work, I was assigned a new laptop. It's a real powerhouse machine with 14 processor cores and 64 gigs of ram. It should be perfect for running my development environment in a virtual machine, but it wasn't. VirtualBox was barely starting, and no matter how many features I turned off, it could ......
- 04/04/2020How many Ventilators for the price of those tanks the Pentagon didn't even want?This goes WAY beyond Trump or Obama. This is decades of poor planning and poor use of funds. Certainly it should have been addressed in the Trump, Obama, Bush, Clinton, Bush, and Reagan administrations -- all of which were well aware of the implications of a pandemic. I want a military prepared to help us, not just hurt other people. As an American I expect that with the ridiculous funding of our military might, we are prepared for damn near everything. Not just killing people and breaking things, but ......
- 01/28/2020Copyright Troll WarningThere's a copyright troll firm that has automated reverse-image searches and goes around looking for any posted images that they can make a quick copyright claim on. This is not quite a scam because it's technically legal, but it's run very much like a scam. This company works with a few "clients" that have vast repositories of copyrighted images. The trolls do a reverse web search on those images looking for hits. When they find one on a site that looks like someone they can scare, they work it like ......
- 03/26/2019Undestanding how OAUTH scopes will bring the concept of APPS to your Domino server
- 02/05/2019Toro Yard Equipment - Not really a premium brand as far as I am concerned
- 10/08/2018Will you be at the NYC Launch Event for HCL Domino v10 -- Find me!
- 09/04/2018With two big projects on hold, I suddenly find myself very available for new short and long term projects.
- 07/13/2018Who is HCL and why is it a good thing that they are now the ones behind Notes and Domino?
- 03/21/2018Domino Apps on IOS is a Game Changer. Quit holding back.
- 02/15/2018Andrew’s Proposed Gun Laws
question and though "wait, I know Tim doesn't do that when skinning our
applications." Since he's 15 feet away, I just asked him, and he replied that
he simply never needed to use any path information when the image resource was
local. But I couldn't have told you with a gun to my head whether that was
because Xpages, Domino or the CSS spec had a rule about how relative paths
worked.
One potentially useful thing I can tell you is that Xpages has some automatic
translation of paths for anything coming from Dojo. And if you drop later
versions of Dojo into a sibling path to the default dojo1.3.2 folder on your
server, it will use those instead. That's how we were able to include some
1.4.1 stuff in recent projects.
Anyway, I'm glad to have introduced anything that will save you work. Sorry
we didn't have this conversation 5 years ago. :-)