tags:

views:

349

answers:

2

Why doesn't asp.net css link path work outside of the head tag?

I have this code in a master page:

<head runat="server">
    <title>Untitled Page</title>
    <link href="../CSS/default.css" rel="stylesheet" type="text/css" runat="server" />
    <asp:ContentPlaceHolder id="head" runat="server">
    </asp:ContentPlaceHolder>
</head>

This seems to resolve the CSS link no mater what folder depth the page is at.

I notice that if you use the css link it only resolves to the correct path if it's in the head (if used in the body it does not work).

I know how to get around it by using ResolveUrl, but I am wondering if this is just how it works or if I'm missing something.

+4  A: 

ASP.NET does some magic rebasing of urls in link and script tags when you specify runat="server" on the head element of a master page.

There are some details of this strange behavior here.

BC
Sounds like this is just how it is. That is very strange. I wonder why they didn't create an asp:link server control that can take a relative path like the asp:image and asp:HyperLink does.
metanaito
@webdtc They did. System.Web.UI.HtmlControls.HtmlLink. It gets instantiated when you do <link runat="server"/>
BC
@webdtc That's what makes the behavior even more strange. The HtmlHead control of the same namespace is sensitive to its literal content, which is not typical of other controls.
BC
My link is runat server and it does not resolve the url.I read http://msdn.microsoft.com/en-us/library/system.web.ui.htmlcontrols.htmllink(VS.80).aspx perhaps if I do it that way it will work the way I expected it to?
metanaito
+1  A: 

Server controls will process relative URLs and will output the appropriate URL to the client. <head runat='server'> is a server control that does this. If you remove the runat='server' attribute, you'll see that this address translation won't happen anymore.

Mehrdad Afshari