Relative urls in css

Aug 4, 2009 at 1:38 AM

How does this library handle css files with relative urls?

For example: img(../../image/logo.gif)

Aug 9, 2009 at 2:34 PM

Any luck finding a work around for this?

Aug 21, 2009 at 6:45 PM

i really liked the idea of this library but a lack of ongoingness from the developers i decided to fork my own implementation. its not here on codeplex but i can share some of the code if you need.

About this particular issue i've included a simple textparser that parses every css and js-document which are in for inclusion and im able to use for example the ~/ syntax, which i prefer over relative urls.

Coordinator
Oct 29, 2009 at 4:17 PM

@theonlylawislov and @quest4denali: I'll look into this and provide feedback shortly.

@burningice: I've just discovered CodePlex doesn't send email notification by default when there's new item in the discussion board.  My bad.

Coordinator
Oct 31, 2009 at 7:27 AM

This is fixed with the latest development code (Combres 1.0 Beta).  Get the code from the Source Code tab, or wait until I make a release (within a day or two from now).

Coordinator
Nov 2, 2009 at 8:27 AM

1.0 beta is out and has this problem fixed.  Download the binary here: http://combres.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=35200

Nov 23, 2009 at 11:47 AM
Edited Nov 23, 2009 at 1:01 PM

Nice plugin. One issue, when resolving the url in the css, if it is the remote url (1.1 it is dynamic, i checked in 1.1 also), it is not showing the full url, it still shows the relative url. For Eg: in css if we have body {background:url(~/Frontend/images/bodybg.gif) and if the css mode is dynamic it should resolve as body {background:url(<remote url>/Frontend/images/bodybg.gif) isn't it? but it is resolving as 

body {background:url("/Frontend/images/bodybg.gif")
Coordinator
Nov 23, 2009 at 3:00 PM

@rgrajan:

Note that the ~ ASP.NET partial path symbol should be used only when your CSS belong to the same web application using Combres.  If it's used in a CSS file not belonging to the same web application, Combres won't be able to resolve the URL probably since it doesn't have the ASP.NET application context of that other application or server.  Remember, the ~ symbol is ASP.NET-specific and only resolved because the Combres filter supports that - it's not the standard CSS thus shouldn't be used for applications not using Combres. 

That said, as it's possible that the other web application turns out to also use Combres (or some other tool which resolves ~) and thus CSS files in that web application have URLs starting with ~, I would modify Combres so that whenever it encounters a URL starting with ~ for a dynamic resource, it would attempt to resolve the URL as though the URL starts with an "/".  This would work most of the time, but if the other web application (which hosts the CSS) is deployed in a virtual directly, this will resolve in an invalid URL.  Will this work for you?  A solution that can full address this requires developers to tell Combres the application path of the web application hosting that CSS.  I'm not sure if the added complexity justifies the use case though.  Therefore, I would delay thinking more about it until somebody reports that it's a valid problem to their application.

On the other hand, your defect report is still valid because even when you don't use the ~ symbol, the current filter doesn't correctly resolve URLs of CSS which belong to another server or web application.  For example, if in the CSS you have body {background:url(/Frontend/images/bodybg.gif) - note there's no ~ symbol, then the expected output would be {background:url(<remote host root url>/Frontend/images/bodybg.gif), but the current filter incorrectly resolves to body {background:url("/Frontend/images/bodybg.gif").

I add a ticket here for tracking the progress of this feature: http://combres.codeplex.com/WorkItem/View.aspx?WorkItemId=5489

Thanks for reporting the issue.

Nov 23, 2009 at 4:24 PM

Thanks for your detailed reply. At the same time relative path (Eg: ../../images/bodybg.gif) is working perfectly with remote url, those who are having this issue can use the relative path until the next release. Again thanks for your valuable time for this wonderful library.

Coordinator
Nov 24, 2009 at 3:05 PM

I've addressed this in the latest code commit.  Let me know if there's any issue.  Note that if you use ~ for remote resources, make sure they don't belong to an ASP.NET virtual directory.