-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Paul,
On 5/15/12 11:05 AM, Paul Singleton wrote: > On 15/05/2012 15:08, Christopher Schultz wrote: > >> On 5/15/12 5:00 AM, André Warnier wrote: > >>> Personal opinion :<Base> tags are evil. They create all kinds >>> of issues when you move the app, or change your server >>> configuration. There shouldn't be any real reason to use them, >>> if your app is structured properly. Relative paths should >>> work. > >> +1 >> >> I only just found out in the last few months that URIs within a >> CSS are /relative to the URI of the CSS/ which blew my mind and, >> honestly, makes total sense. > > A JSP developer needs to know how (and when) references are > resolved in at least these cases: > > <%@ include file="foo" ... <%@ include file="/foo" ... > > <%@ page errorPage="foo" ... <%@ page errorPage="/foo" ... > > <%@ taglib uri="foo" ... <%@ taglib uri="/foo" ... > > <jsp:forward page="foo" ... <jsp:forward page="/foo" ... > > <jsp:include page="foo" ... <jsp:include page="/foo" ... All of the above should be covered in great detail in the JSP specification. They are interpreted 100% on the server side. http://jcp.org/aboutJava/communityprocess/mrel/jsr245/index.html > <link href="foo" ... <link href="/foo" ... > > <script src="foo" ... <script src="/foo" ... > > <img src="foo" ... <img src="/foo" ... All of the above will be (according to HTML) relative to the currently-displaying page's URL (back to the last / in the first example in each) or relative to the host (in the examples starting with /). They are interpreted 100% by the client. http://www.w3.org/TR/WD-html40-970917/htmlweb.html > <style type="text/css"> p { background:url(foo) } ... <style > type="text/css"> p { background:url(/foo) } ... If this is in page markup (as you have here), then the URLs behave exactly as described above for the HTML rules. If they are in a separate CSS file, then all URLs are relative to the URL of the CSS file itself. Any relative URL on a page that contains a <base> tag will be relative to the base tag's URL instead of the current page's URL. http://www.w3.org/TR/css3-values/#url > [surely there are more, e.g. within in-page JavaScript?] In-page Javascript follows the same rules as everything in the HTML, since you are manipulating DOM elements which follow HTML rules. If you ask an element for its URL and then try to, say, open an XMLHttpRequest to it, I don't know if the fully-qualified URL is used, or if the browser resolves the URL relative to the current page. I suspect that the latter is true, the result is the same, and it just works as one would expect. > What *nix minds think of as an "absolute" path e.g. /foo is just > relative to something other than what foo is relative to. URLs beginning with / *are* relative. Absolute URLs must include the protocol, etc. and so generally (on the web) begin with http(s)://. > I'll try to find a small prize for whoever is first to provide > links to clear, definitive documentation of how each case above > resolves ;-) Give the prize to Google. It's very good at finding things like "html relative url" and "css relative url" and "jsp 2.2 specification". >> I can't see a really good reason to use a<base> tag these days >> unless you want fully-qualified paths for all URLs and want to >> save on bandwidth or something like that. > > We found one Please explain. I'd love to hear it. > but if you are just using <base> empirically, to make things work > when you don't really understand "relative paths", then it's > probably worth time spent figuring out how to manage without it. +1 Using the <base> tag is just likely to mask other problems in your webapp. Also, <base> doesn't work on the server ;) - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+ydjcACgkQ9CaO5/Lv0PAT6gCgrfOjTLnGA2oiQ8v4aYgWPt2R fwYAn3T8EgIRS+aYCGQL4RoBYoEsi0Vt =+tP+ -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
