Might be a silly question, just wanted to know do the following ways on including CSS have any impact on the server response time. If yes, which is the better method and how
Way 1 :
<link rel='stylesheet' href='css/some.css'/>
Way 2 :
<link rel='stylesheet' href='http://www.somesite.com/css/some.css'/>
No, your browser converts any URL into an absolute URL before making the request, so it won't make any difference.
Depends. If you want to have the same website to run in the dev, test as well as prod environments without changing code, you'd like to use relative paths. Instead of that you can also specify a <base> element so that you only need to specify the domain only once -if necessary dynamically using a server-side language.
Another thing to take into account when hardcoding the protocol (the http: part) is that you would like to use at least protocol-relative URL's when your website may switch between HTTP and HTTPS regulary. A CSS file which is hardcoded on http://example.com/style.css may cause security complaints in most webbrowsers about "unsafe content". In such case you'd like to use relative paths such as style.css or if you persist in using the full domain name, use //example.com/style.css instead. This by the way also applies on all other resources like Javascripts and (CSS) images.
Related
I'm brand new to SSL certificates, but I've just installed one on my site.
I link to my CSS, JS, Images etc like so:
<link rel="stylesheet" href="css/style.css">
However it is now blocked as coming from an unsecure location.
If I change it to this, it works:
<link rel="stylesheet" href="https://...com/css/style.css">
Is there a way to force "css/style.css" to be secure? Or do I have to rewrite some portions of my code?
Any help appreciated thanks
You don't need to use an absolute URL, as the two previous answers (wrongly) suggest. If you called the main page via HTTPS, then a relative URL such as css/style.css is resolved to an absolute HTTPS URL automatically. Why this doesn't work in your case, is impossible to say without seeing a live example.
Are you by any chance using the base element inside your HTML? If that is set to an HTTP URL, then that would of course screw up the automatic resolving of relative URLs to HTTPS.
Turns out you did have a base element, and it was the culprit.
I've got <link rel="icon" type="image/png" href="myimage.png" />, why doesn't it work? It gives me the blank/new document icon in the favicon.
Does it have to be an icon.
Does it have to be from a URL?
It worked previously but it's stopped now, I might have changed something, but I don't think so, I didn't update anything, add any gadgets or anything, it just stopped working.
I have tried a few things such as using URL or an .ico instead of PNG, and I've looked online too, but I can't figure it out. It could be because I'm hosting the site file in a google drive sync but I doubt it somehow.
Thanks. In case anybody needed it, I've got the code on paste bin: http://pastebin.com/Wzc9zLea << HTML and CSS
You need to meet the specifications => PNG/GIF/ICO, 8- or 24-bit colors, and size 16x16 or 32x32, which your image doesn't meet at all. By the way, why do you wrap your code with <a> tags?
P.S. - You might want to remove 'shortcut.'
To answer your questions, whether it has to be an icon–I think you mean whether it has to be a .ico or a .png file, and that depends on the browser. As a general rule, most of the time it can be a png, no problem. For much more detail, check out this SO answer.
As for whether it has to be "from a URL", that's tough to give a yes/no answer to because it's a bad question. If you mean, does it have to be from an external URL accessed via the HTTP protocol, then no, it doesn't. It can be a file path and that works just fine. Anything that requires a URL will generally take a file path no problem.
Side notes:
As I mentioned in my comment, there's no need to wrap your code in <a> tags, and it may be screwing with your code.
Some people are saying you don't have a closing <head> tag, but I see it just fine, so not sure what that's all about.
Your favicon should be saved as a .ico filetype. Place the NAME.ico in the root of wherever your website is. You can go to this site http://www.favicon.cc/ and have your .png made into a favicon. Then just put it into the root and you're set.
It varies depending on the browser and these days the device (tablet, smartphone, etc). But at a minimum, your favicon link should be constructed as follows:
<link rel="icon"
type="image/png"
href="http://example.com/myicon.png">
Currently, your file reference is relative to URI, meaning that if you have pages deeper than one level below your document root, your code is going to break. To illustrate, here's an example:
If you visit http://example.com, the browser will look for your favicon file at http://example.com/myicon.png.
If you visit http://example.com/mycategory/myarticle.html, the browser will look for your favicon file at http://example.com/mycategory/myicon.png, which won't be found.
See the problem? So either use an absolute path to your favicon file:
<link rel="icon"
type="image/png"
href="http://example.com/myicon.png">
or make the path relative to your document root:
<link rel="icon"
type="image/png"
href="/myicon.png">
Looking at the HTML you posted, another obvious problem that stands out is poorly structured (invalid) HTML. Remove the first four lines in your HTML document:
1. HTML
2. <a>
3. <!DOCTYPE html>
4.
The first line is just text and will confuse browsers trying to determine the document type of the page being loaded. The second line is a valid HTML element but it needs to exist within parent
<html>
<body>
...
</body>
</html>
elements. The third line isn't a valid declaration and looks like a stab in the dark, and the fourth is a blank line. If you don't actually know what HTML standard you're coding to, it's probably best to simply omit the DOCTYPE declaration and simply let the browser guess the standard to use because this WILL affect how your HTML is interpreted (and rendered). I don't know if it's universally true, but I think most browsers will fall back to the loosest HTML standard in the absence of a defined DOCTYPE.
One final thought. If you're new to HTML and/or don't have any sort of formal education/training, take some time to go through online tutorials. http://www.w3schools.com is a basic resource that can help you better understand the language.
For my webpage http://www.example.com/homepage.html which is the best way to link static resources, such as CSS files?
http://www.example.com/css/base.css
http://example.com/css/base.css
/css/base.css
Neither is better.
One will survive moving the linking document to a different location. The other will survive moving the entire tree to a different location.
In most cases, the latter is more useful (as it lets the links work between environments (development, staging, test, production)) but your needs may vary.
Relative path is best way to use.
Ex : http://www.example.com - Absolute path
Relative path
var style="css/base.css";
var style1="css/base1.css";
Then, Absolute path+style;
or absolute path+style1 . We can able to change relative path without hard coding.
For internally-served resources, typically you would use a relative URL, for the reasons stated by Quentin (upvoted accordingly).
However, absolute URL's are useful in some important scenarios that you should be aware of, for example:
When you use a CDN (content delivery network) to serve your static files (such as the CSS files you mention in your question) more quickly. These are served from other servers than yours, so you have to fully specify the location.
When you need to change the protocol. The most common case is switching to https, e.g., for actions like signins and purchases.
If you are putting links into an email, where of course relative paths won't go anywhere. This isn't relevant for loading a CSS file, since styles are inlined in HTML emails, but still it's a case to consider, e.g., for images.
I serve content from a subdirectory on my web server, for example:
http://www.myserver.com/subtree
I notice that the CSS is not rendering correctly, so I look at the source of the HTML file:
<link rel="stylesheet" type="text/css" href="static/stylesheets/style.css"/>
One would expect that browsers such as Chrome or Firefox attempt to find this css at
http://www.myserver.com/subtree/static/stylesheets/style.css
When hovering over the link, I can see that it links me to
http://www.myserver.com/static/stylesheets/style.css
It may be useful to note that I'm using apache's mod_proxy to serve the content from /subtree from another server running on the local machine. However, my reasoning is that the browser doesn't know about this and it looks like the content is coming from myserver.com/subtree so therefore it should look for the resources using the relative path.
What am I missing?
That's to be expected. The browser cannot know that /subtree is a folder (instead, it could also be just a file served as text/html). If you want the browser to include this path fragment in relative path lookups, make sure that it ends with as slash, as in:
http://www.myserver.com/subtree/
If you are using Apache, you can use mod_dir's DirectorySlash directive to automatically fix this for you: mod_dir documentation
I hope this help:
Browsers when see URLs which start with /, they remove the path part of the document.location.href, or get the value of document.location.origin and append the current URL to the end of it.
When they see URLs which don't start with '/', they append the current URL to the end of document.location.pathname.
From a comment by Sam Dufel on the question:
I've noticed that with friendly URLs,
browsers will often look in a
different relative path depending on
whether or not you include a trailing
slash. I.E,
http://www.myserver.com/subtree would
have a relative root of
http://www.myserver.com/, and
http://www.myserver.com/subtree/ would
have a relative root of
http://www.myserver.com/subtree/
(here so you can mark this question as answered)
I have a site with static HTML pages in the home directory. These HTML pages use relative paths to refer to images, css, and links i.e.
<img src="images/myimg.gif">
and
Contact Us
I also have a monolithic script whose URL is, i.e. http://mysite.com/myScript which uses "extra path info" to select functions... i.e. http://mysite.com/myScript/products shows a list of products. So in HTML generated from the script I need to refer to images, css and links like this:
<img src="../images/myimg.gif">
and
Contact Us
The problem is now I want to start moving common HTML into include files, (e.g. common header and footer), but the fact that the script and the static HTML refer to relative resources in different ways is complicating matters.
I don't want to use absolute paths because that messes up my colleague's work when she tries to work on the pages in DramWeaver, and it also makes the site less flexible.
What's the best way to solve this issue? One idea I had was to use URL rewriting in Apache to allow the URL to http://mysite.com/products to really use http://mysite.com/myScript/products but I don't have experience with URL rewriting so I don't know how easy that would be. Another idea I had was to use the META BASE attribute in HTML but I don't like the fact that I would have to hard-code that into every HTML page, and it would have to have the full URL hard-coded (e.g. http://mysite.com/) into each one. Any advice?
Can't you refer to your images with a slash at the beginning so all files linked to are from the root, no matter how deep you are in the directory structure you are? E.g:
<img src="/images/myimg.gif" />
EDIT:
You could use $_SERVER to get the path then use substr_count to count the number of slashes in the path. Add as many ../'s as you need based on that number. Would that work for you?