tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: Links in CSS vs JSPs
Date Wed, 21 Sep 2011 14:13:48 GMT
Hash: SHA1


On 9/20/2011 4:45 PM, André Warnier wrote:
> Christopher Schultz wrote:
>> You can't do this unless all your JSPs are at the same directory 
>> level, say, in "myapp".
> Why not ? Suppose all stylesheets are in
> (tomcat_dir)/webapps/myapp/css/, and all images in
> (tomcat_dir)/webapps/myapp/images/, then if you have this JSP in
> e.g. (tomcat_dir)/webapps/myapp/level2/mypage.jsp, and it refers to
> a stylesheet, the link should be "../css/mystyle.css", that's all. 
> And if you have this JSP in e.g. 
> (tomcat_dir)/webapps/myapp/level2/level3/mypage.jsp, and it refers
> to a stylesheet, the link should be "../../css/mystyle.css", that's
> all. (You always know where, *relative to your JSP*, the stylesheet
> is.)

The URLs are relative to the resource's URI, not the file. So, if you
have one file include another file like this:

<%include src="subdir/subpage.jsp" %>

<link rel="stylesheet" href="../css/my.css" />

This presents a problem because the browser is looking at
http://host/webapp/main_page.jsp and the CSS reference points to
http://host/css/my.css instead of http://host/webapp/css/my.css.

> And if any of these stylesheets refers to an image, it should do it
> as "../images/image.jpg", because by the time the broser fetches
> the stylesheet, the "base href" is the URL whence the stylesheet
> came from

Correct. That's nice, but only if you can get the stylesheet loaded
properly in the first place.

It's standard, common, and recommended practice to make all URLs
relative to the webapp by using the tools provided by the servlet spec
to effectively build all URLs like this:

<a href="<%= response.encodeURL(request.getContextPath() +
"/my/relative/url")" %>

All JSP tags, etc. use the same technique and it's more consistent to
use those tools to build all URLs instead of special-casing all .css
resources or whatever. This also avoids the problem of
multi-directory-level file inclusion.

> The doubt comes only in a (contrived) case like the following : 
> Imagine you have a JSP containing a link to a stylesheet as follows
> : <style
> src="utilities/servlets/css_servlet?css=somedir/mystyle.css" ..> 
> (with "css_servlet" being some code which cleverly retrieves the
> named css file from somewhere else altogether), then by the time
> the browser gets this stylesheet, it thinks its base path is 
> ""

That depends upon the URI of the top-level page, not the exact file
that is generating content at a given time. See my example above.

All I'm saying is that it's safer to use relative-to-the-context-root
URIs than any other strategy to avoid these errors.

> The point is, if you use relative paths properly, then you can zip
> your entire app, give the zip your designer who will unzip it in
> his directory /chris/project1/, and work on it with a local html
> design tool. When he/she is done, "it" will zip it again and send
> it back to you to unzip wherever you feel like (at
> webapps/my_newapp if you like), and all links should still work.

If you are using JSP and your designer is expecting to read
non-dynamic files directly from the disk (with no JSP interpreter),
things are going to go badly. Most non-trivial webapps using JSPs have
many includes, forwards, etc. in order to build a single page and it's
just more complicated than you are making it sound. Projects like JSF,
Apache Tiles, etc. all muddy the waters even more for a "pure"
designer and make it next to impossible to use a zip-file-of-the-JSPs
as a basis for editing.

> It's only if you start playing ganes like above that everything
> falls apart.  And as soon as you start using absolute links ...
> forever rule you it will, the dark side of the force.

Remember, the Dark Side kicked some serious ass.

Seriously, relative-to-the-context is the way to go.

- -chris
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla -


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message