I used to think that everyone used relative paths (e.g. /styles/style.css). But I wonder why some popuar web designers (e.g. http://www.getfinch.com and http://31three.com/) use absolute paths (http://example.com/styles/style.css).
So basically I'm asking why some professional designers are using absolute paths instead of relative paths?
Both of those are using ExpressionEngine CMS, it's probably the way the CMS links the stylesheets.
But really it's just a matter of preference. Personally I go with root relative /css/main.css because this way if I'm developing locally + offline I don't have to worry about switching the WEB_ROOT constant to a local one ( less hassle + shorter ).
The only case I see for absolute is if the domain uses a CDN ( content delivery network ) and the domain is different from the origin domain.
Good thread on Google Webmaster Central... Discusses about Google crawling perspective and easy of migration.
Relative Paths
I don't think either make too much of a difference. Using relative paths is easier while working offline and then uploading the website.
Also if you were to ever change the domain and want to still keep your site. You will only need to change the absolute links that you have referenced, the relative links will work just fine.
Absolute Paths
A browser can only download 2 files from a server at any given point of time. Also, while it downloads JavaScript it does not download anything else. So to circumvent this 2 file limit, a lot of people use sub domains. like : http://css.example.com/style.css -- this is to increase page load speed. You can't achieve this effect using relative URLs.
One place where you will need to be careful of your absolute paths is when you are making AJAX calls. If you hard code into your javascript, a call to the url : http://www.example.com/ajaxfile.php -- the AJAX call will work fine from http://www.example.com/index.php but not from http://example.com/index.php -- this is because of the same origin policy.
I would say either personal preference (most likely), or portability, if your files are referencing a fully qualified URL you don't need to include those files when using the html elsewhere, it'll continue pulling from the remote site.
It depends more on the platform than anything else in my experience, for example .Net uses ~/ for application root, which renders as /path/file.css in the HTML, just because that's an easy path to render from the code side...path of least resistance deal there.
Another case would be if you're loading stuff from another domain, for example sstatic.net here, you don't have a choice really, it has to be fully qualified.
I think it's only a matter of preference. I prefer relative URLs because it's less of a pain to change if you're changing (sub)domains. But if you have a CMS or blog it usually handles that for you anyways (e.g. {SITE_URL}/path/to/page).
I think some Apache Redirect Rules have problems with relative paths. Choosing the absolute path assures that the .htaccess file is hit.
it depends on the application that you are building, for example. your application uses mvc framework, like the one in your example, they have to use absolute paths because the css they are calling does not belong to the relative path in each page.
using mvc framework does not mean you have to use absolute paths but you can also use relative paths. This is just my preference.
Not sure about those specific sites, but often people use different urls for static resource files for efficiency purposes (not personal preference). Most browsers have a limit on the number of concurrent connections to a single url while loading the page, and you can bypass that restriction by serving files some files from a different url, which would require an absolute path. This helps pages load faster and is a common practice.
Aside from the obvious portability issues, absolute paths are not a good idea if the content is on the same domain because it can cause extra DNS lookups in certain browsers. Keeping domains relative to the root of your site whenever possible can help boost performance unless you have a CDN or separate set of domains to host static content from.
Hope this helps!
Also, sometimes, if the code is server-side, there may be a variable that is printing out the full URL. If I remember correctly, usually in WordPress themes that is how they output the proper directory.
Some people would even say that paths that start from a domain's root (e.g. /styles/style.css ) are absolute (and, consequently, problematic).
Here's the thing: both absolute/fully qualified schemes and relative schemes solve problems related to what happens when you move things around. But they solve different problems. With a fully relative scheme, you can move everything related to the document around to a different path on the server and you won't break things. With a fully qualified (and some absolute schemes), you can move any individual document around and not break things.
I tend to find that I move things in groups more often than I migrate an individual document, so I tend to use fully relative schemes. Other people may have different needs.
The reason I always have heard is that it is for SEO optimization when linking to pages on the same domain. I am not sure if this is something kept from the dark ages of web development or if this is still true but this is the rationalization I am always given.
The way I get around this is I use the base attribute in my header so that I can get the benefit of relative urls. This way I can test on my development server and just change the base url or comment it out completely. Although all your relative urls will need to be written like they are navigating from the base url set.
If your page gets called using https protocol, any relative path css will be called using https protocol as well. Are you really need to encrypt/decrypt css contents? :D
However, if you use absolute path referring to an external css, you can specify the protocol to use, generally http rather than https.
