Specifying .aspx on the end of a css file? - asp.net

Question

When working on web apps in ASP.NET, what is the reason for specifying a file as stylesheet.css.aspx rather than just plain stylesheet.css? I have seen this done in various web apps.
The web designer mentioned something about how it's a .NET thing and storing a global variable for the ASPX page but I didn't really understand, nor know the full story.
This is done at my work for a large web app with different sites for different countries. This makes me wonder, when would I make separate web apps for separate countries as opposed to one web app serving different languages? Is there a performance, architectural or other technical reason for doing so? I can think of several non tech reasons (e.g. SEO considerations).

Answer 1

Probably the stylesheet is not static and is dynamically generated on the server.
This technique can be used to provide a different style sheet by considering several parameters (such as user theme selection or something).
Clarification: While you can map .css extension in IIS to be handled by ASP.NET. It has two problems:
Static CSS files will also get handed down to ASP.NET runtime, which will cause a small performance loss.
In many shared hosting environments, you don't have any control on IIS handler mappings.
Web browsers don't care (at least, they shouldn't care) about the extension or anything else about the URL. The only thing they should care about is the Content-Type header. It should be set to text/css; otherwise some of them may complain.

Answer 2

A stylesheet is just a text file - you can specify any file extension you want as long as your <link> matches. In other words this will work:
<link type="text/css" rel="stylesheet" href="style.foobar"/>
as long as your stylesheet has that name. I can't think of any reason for naming the stylesheet with a .aspx extension as it is misleading and confusing. [Other posts have good explanations for why this might be used.]

Answer 3

As mentioned, its to allow the server to process it as an aspx file. It will spit out css I'm sure, but will allow you to do processing server-side.
In the example you gave, if you have the same html content for different regions (perhaps translated, but the same structure), then by having a dynamic css file you can swap out, say, background images. Generally this is considered to be a bad idea, as you should be adding different class names to the html elements to solve this problem.
Another common reason for doing this is to avoid duplication of color definitions. Technically, you can avoid this also by using class names, but it becomes rather annoying. Most people want to have something like:
define sitebordercolor #999;
define sitebackgroundcolor #fff;
and then in their CSS, be able to do:
.foo { border: 1px solid #sitebordercolor; background-color: #sitebackgroundcolor; }
However, CSS doesn't let you do that. So, by using ASPX files, you can achieve the same result:
.foo { border: 1px solid <%=sitebordercolor %>; background-color: <%=sitebackgroundcolor %>; }

Answer 4

If you name a stylesheet .aspx, it will be processed by the ASP.Net engine rather than simply served as a text file.
Once you're in .Net, you are free to write your CSS on the fly. I'd prefer parameterized css.aspx though, since browser want to cache CSS files.

Answer 5

Stylesheets are usually static text files, there's no reason for giving one an .aspx extension unless they are being dynamically generated.

Answer 6

Mehrdad's answer is spot on with regards to the CSS files - that's how we enable dynamic colours on a number of our sites - have the colour defined by a query string, enable page caching varying by that query string, and there you go.
In response to the architecture part of this question:
Whilst SEO considerations would recommend that localised content is often served from a local server and domain (i.e. French content on a .fr domain for example) this often isn't possible.
In terms of maintenance, it's easier to maintain one web site rather than multiple - so you would build it once, take advantage of the framework features to enable localisation (resource files, etc), and then you can either deploy that to one location or multiple as you see fit.