I am unable to apply a background image in my HTML document using the following code in CSS:
body
{
text-align:center;
background-image:url('C:\wamp\www\marks display\WI71.jpg');
}
I also searched for it, but I found, the above declaration is true but unable to execute it. Why is this happening?
That's not a URL, that's a file path.
If the root of your site is marks display, probably you want this:
background-image:url('/WI71.jpg');
Path should not be map to a drive(file path) when publishing on web, it should be a URL.
It should be like background-image:url('http://domainname/71.jpg'); -- Complete Url of Image
or background-image:url('WI71.jpg'); -- Relative url
buddy html css in reality is actually a on server thing so below is the right code:
background-image: url('c:/xyz/xyz/sample.jpg');
however if you are uploading your site on a real web server do not gives paths like that, just make it like below
background-image: url('foldername_if required/imagename');
The string C:\wamp\www\marks display\WI71.jpg does not comply with URL syntax. To begin with, the character \ as such is not allowed in URLs; it should be replaced by the slash /. The space character should be %-encoded as %20. Finally, to refer to a file in the local system with a pathname, use a file: URL:
background-image:url('file:///C:/wamp/www/marks%20display/WI71.jpg');
However, IE has very permissive error recovery here, so your malformed code actually works on IE, if the file exists in the place indicated with the name given. Other browsers require correct code (mostly).
Such URLs are of very limited usefulness. They mostly work in local testing only, and even in local testing, it is better to use URLs that are relative to the location of the HTML document. This way, you can use the same code in local testing and on a web server, provided that you replicate the relevant parts of the folder structure.
Related
I was sent a hyperlink to a Tableau Public link by a client. When I tried opening it, I got a 404 exception. I wrote back to the client but was told by the same that the link was working fine. I visited his profile page and was able to open the presentation there, but the URL that ended up working was slightly different than the one behind the original, non-functioning link.
Here's the anonymized URL behind the original link
https://public.tableau.com/profile/[client_name]%23!/vizhome/Project-AirportDelay/FlightPerformancesinUSA?publish=yes
And here's the URL via the profile page:
https://public.tableau.com/profile/[client_name]#!/vizhome/Project-AirportDelay/FlightPerformancesinUSA
The only differences I see are ?publish=yes and %23!. I tried appending the former, ?publish=yes, to the working URL, and it was still functional. So I suspect that it has to do with the other difference %23! vs. #!. Could the first work because he is opening it from his computer where he is likely logged onto Tableau Public? What's the difference between these syntax? Any ideas about why the original hyperlink might not be functional?
For obvious privacy reasons, I can't provide the whole URL.
It looks like the basic URL pattern for passing filters ?publish=yes
and
%23 is the URL encoded representation of #
The first # after the authority component starts the fragment component. If the # should be part of the path component or the query component, it has to be percent-encoded as %23.
As # is a reserved character, these URIs aren’t equivalent:
http://example.com/foo#bar
http://example.com/foo%23bar
There are countless ways how a URI reference could become erroneous. The culprit is often a software, like a word processor, where someone pastes the correct URI, and the software incorrectly percent-encodes it (maybe assuming that the user didn’t paste the real/correct URI).
Copy-pasting the URI from the browser address bar into a plain text document should always work correctly.
I use the following syntax in my application so that images are loaded over https or http depending upon how the page was loaded.
<img src="//path_to_image.jpg">
This works fine in Chrome but firefox does not display any images.
What can I do to fix this ?
The // use to support multiple protocol (i.e. http or https), these type of URL is known as "protocol relative URLs" and use with complete domain name. Mostly CDN url are used with //.
If you are planning to use // make sure you use full domain url (i.e. //xyz.com/images/path_to_image.jpg). If you just want to use relative path from the root then use single slash (i.e. /)
Following like help you to understand // usage
Two forward slashes in a url/src/href attribute
Using // will only work with a full URL ('//yourhost.tld/directory/path_to_image.jpg'). In your case one slash /, should be enough!
I have an HTML document I'm transforming with an image whose source url looks like this:
"../foo/bar/baz.png"
I'm using a tritium function to absolutize image source urls, but the ".." seems to be stumping it. It's prepending the hostname, etc, but when it does, it adds one too many layers.
So for example, the correct URL of the image is:
"www.host.com/foo/bar.png"
But the page on which it appears is at "www.host.com/site/baz/page.html"
The source of the image in the original html is therefore "../foo/bar.png"
But the absolutized result I'm getting is: "www.host.com/site/foo/bar.png"
In other words it's going up the file tree to "/site/", but it needs to be going up one more. I don't really see how it even works on the original page without another ".." How should I be handling the ".." in the url?
.. means to traverse one level up; you are using a relative path, not an absolute one like you should be. Drop the dots:
<img src="/foo/bar.png"> will load the image from the root of the domain.
There is a huge difference between src="/foo/bar.png" and src="foo/bar.png" (Notice the slash after the first double quote)
First one points to http://example.com/foo/bar.png NO MATTER what.
Second one, however, (without the beginning slash) is relative URL so the output path depends on the file on which the image appears.
That is why you were getting "www.host.com/site/foo/bar.png" (one level up relative to the file path).
Two solutions:
1) src="/foo/bar.png" OR
2) src="../../foo/bar.png"
I always recommend the first approach because even after you move the files around, you won't have to change the absolute URL. (I learned it the hard way)
P.S. this rule applies to CSS files as well. (for example when specifying the background image URL) If you use absolute paths, you won't have to bang your head on the wall when you change the directory of the CSS file.
As you're in a Moovweb project, I would suggest manipulating the problematic src before you use the absolutize() function.
Is there an easy way you can select the image using Tritium? I'd suggest doing that, then manipulating the src attribute:
$("./img[#id='']") {
attribute("src", "/foo/bar.png")
}
After this, you should be able to use the absolutize() function and the src will be rendered correctly.
I set the base tag as such:
<base href="http://mnapoli.github.com/PHP-DI/">
Then I would like to create a link to http://mnapoli.github.com/PHP-DI/ in relative path.
I tried:
link
and it works in Chrome, but is this method standard and supposed to work on every browser?
Although href="./" as suggested in Mike’s answer is better (easier to understand to anyone who reads the code), the answer to the question posed is that using an empty URL is standard and supposed to work on all browsers. According to STD 66, a relative URL with no characters (path-empty) is allowed, and by rules on relative URLs, it is resolved as the base URL.
This has nothing to do with folders or files; URLs are strings, and whether they get mapped to folders or files on a server is at the discretion of the server.
I would do something like this:
<base href="http://mnapoli.github.com/PHP-DI/">
Home
Hi I am making a chrome extension. Where I save a page to the database as a string and then open it later as a dataURI scheme like:
d = 'data:text/html;charset=utf-8'+encodeURI('HTML TEXT')
location.reload(d);
The problem with this is that the page, say its name is http://X/, in which I executed the above command loses the javascript files in its head.
I considered using the document.write(d), if d has a string appeneded to it with the <head>...</head> of http://X/.
But this opens a big vulnerability problem for XSS. At this point I am trying to think of white listing tags when I save the original page... is there another way?
I'm not sure what you mean by http://X/, but if want copied website to retain its origin (i.e. have code you give run exactly as if it were downloaded from http://X/), then I'm afraid it's not possible with standard DOM methods (it would be a security vulnerability that bypasses same-origin security policy).
If you want to run 3rd party sourcecode safely, then use this:
<iframe sandbox src="data:…"></iframe>
You could modify the source and insert <base href="http://X/"> in there to make relative URLs work properly.