as I strive to come up with the best methods name in my designs I struggle on a simple question but still very confusing to me.
There are two ways I use for retrieving stylesheets or javascript files:
<link href="/myProject/public/styles/master.min.css?v=1274382274" media="screen" rel="stylesheet" type="text/css" />
<link href="http://mydomain.com/public/styles/master.min.css?v=1274382274" media="screen" rel="stylesheet" type="text/css" />
<script type="text/javascript" src="/myProject/public/scripts/master.min.js?v=1274394222"></script>
<script type="text/javascript" src="http://mydomain.com/public/scripts/master.min.js?v=1274394222"></script>
I know that http://[...] can be called as an URI (as specified by the difference between URI and URL)
but an href or src that specifies a path according to the document root of the server such as /myProject/public is different.
So what would be the best term when speaking of those two different href|src value's?
/myProject/public/[...]
http://mydomain.com/[...]
An URI since it specifies a location and an identification?
An URL? Not sure why
A path? A definitive no IMO
Another term, please specify and explain
My design is independant of both the href and src, otherwise I would just have used the two terms href and src, of course. So in summary, I need the term that specifies the above while speaking about both about the href and src.
Thanks!
I believe the linked question perfectly answers your question. Nothing more to say. All URLs are URIs but not vice versa. Both of the examples you wrote all URLs (and consequently URIs too). The first is a relative URL and the second is an absolute URL. Both are URLs as they locate a resource. URNs are, for instance, URIs but not URLs. They identify a resource but provide no means to locate it.
What is hidden by a definitional approach (i.e. "every A is B") is that the "URI vs URL issue" is indeed historical.
The term "URL" was used in specifications only for a few years. However this was exactly the years where the Web became popular. So everybody learnt about "URLs", "sites", "pages", "addresses", and even if the W3C strived for erasing these questionable terms and concepts from people minds, the harm was done.
Related
After a deep search, there is something to be known by me which puts me to think a lot and couldn't get the idea of the purpose that it serves. Which is capitalizing the S in stylesheet for rel attribute value.
what is the difference between,
<link rel="stylesheet" href="/css/widgets/some.css">
and
<link rel="Stylesheet" href="/css/widgets/some.css">
what purpose does it serves? An on-shore 15years experienced web application head is insisting to do this. Please explain and make me understand.
There is no difference, as link types are case insensitive. I am guessing that your colleague prefers them that way for some reason.
Please, explain what does "?v=1" mean in <link rel="stylesheet" href="css/style.css?v=1">?
Thank you!
It's an informal way of versioning external resources, and of controlling whether they are cached. You increment that number when the file changes, guaranteeing that all browsers load the new version. The number isn't actually used anywhere - it's just a way of uniquifying the URL for the current version of the file.
In a Wicket 1.4 app, I have some static CSS & JS resources under [project root]/WebContent/css and [project root]/WebContent/js respectively.
My Wicket HTML files are in src/resources/fi/company/product/pages with corresponding Java classes in src/main/fi/company/product/pages. (In the resulting WAR file, the HTML & property files are of course in the same places as Java classes.)
The HTML files contain references to the resources such as:
<head>
<link rel="stylesheet" type="text/css" href="css/main.css"/>
<script type="text/javascript" src="js/calendar.js"></script>
</head>
This works fine everywhere (or so we thought until recently). NB: my Java code does not reference these resources at all.
Looking at the source of a rendered page (whose URL is e.g. http://localhost:8080/report/42.4 or http://localhost:8080/?wicket:interface=:6:::: ), the resource reference appears as:
<link rel="stylesheet" type="text/css" href="../css/main.css"/>
However, we just noticed that when the app is deployed somewhere else than (Tomcat) root, the resources break on non-bookmarkable pages.
In other words, when the URL is e.g.
http://localhost:8080/foobar/?wicket:interface=:2::::
and a page refers to
<link rel="stylesheet" type="text/css" href="../css/main.css"/>
...the browser tries to fetch the resource at the invalid URL
http://localhost:8080/css/main.css
Now, what is the simplest (yet non-hacky) way to get these static resources working, regarless of the deployment path?
I could switch to using bookmarkable pages exclusively (which would require changing the constructors of the pages), but I suppose that shouldn't be necessary...
Edit: Looks like I got CSS resources working (on most places) simply by using <wicket:link>, as advised in this answer:
<head>
<wicket:link>
<link rel="stylesheet" type="text/css" href="css/main.css"/>
</wicket:link>
</head>
However, now the CSS references are broken on a page with an URL like http://localhost:8080/foobar/report/42.9
Wicket is trying to do something strange with the "css/main.css" path:
ERROR org.apache.wicket.RequestCycle - Can't instantiate page using constructor public fi.company.product.pages.ReportPage(org.apache.wicket.PageParameters) and argument 0 = "css" 1 = "main"
org.apache.wicket.WicketRuntimeException: Can't instantiate page using constructor public fi.company.product.pages.ReportPage(org.apache.wicket.PageParameters) and argument 0 = "css" 1 = "main"
at org.apache.wicket.session.DefaultPageFactory.createPage(DefaultPageFactory.java:212)
at org.apache.wicket.session.DefaultPageFactory.newPage(DefaultPageFactory.java:89)
at org.apache.wicket.request.target.component.BookmarkablePageRequestTarget.newPage(BookmarkablePageRequestTarget.java:305)
Edit 2: Actually I'm not sure if <wicket:link> is the right solution here, since these resource files are not "class path resources". I guess my question is, can you make this work while still using web context resources (i.e., without making these class path resources)?
Right, I solved it, and the solution turned out to be very surprising.
Earlier I wrote:
A curious thing is that without any changes, it seems I can no longer
reproduce the problem...
That wasn't quite true, as I had made one small change (that I thought was inconsequential): I had deleted a file WebContent/index.jsp which in our project was a remnant that served no purpose.
Once it dawned on me that this could have fixed it, I did some more testing, and indeed:
For static resources to work as expected, you must not have an index.html or index.jsp file in the root web content directory (i.e., the parent of the CSS and JS resource dirs), as that in some cases breaks ../ references.
This probably isn't even Wicket-specific, but perhaps it is Tomcat-specific—if anyone knows more, feel free to chime in. I'm dubious whether this question ever helps anyone else, but still, glad I got it working!
I have a page that has translations available in a variety of languages. I'm trying to be a good HTTP citizen:
I return the correct version based on the Accept-Language header
I return a Vary: Accept-Language header
(The users of my site can override these settings in their user profiles, but I don't think that's relevant to the discussion at hand.)
How do I get search engines to index all the variants?
Later
The Google Webmaster Central Blog recommends using URLs and against using Accept-Language to detect language. Their solution would certainly work, but it seems anti-HTTP.
It is highly recommended to use different domains for different languages:
fr.mysite.com or mysite.fr for French
ru.mysite.com or mysite.ru for Russian
A less preferred method that would still work for SEO is to use sub-directories to differentiate:
www.mysite.com/fr/ for French
www.mysite.com/ru/ for Russian
Sometimes session is used to identify the language being served. This is not recommended for SEO - search engines will not see different languages.
References:
http://support.google.com/webmasters/bin/answer.py?hl=en&answer=182192
http://www.seomoz.org/blog/seo-guide-international-versions-of-websites
The best way is to use the "Canonical Tag" and the "Alternate Tag". Thats what a SEO would say. What they mean by this is
<link rel="canonical" href="http://www.yourdomain.com" />
<link rel="alternate" hreflang="de" href="http://de.yourdomain.com" />
<link rel="alternate" hreflang="en" href="http://en.yourdomain.com" />
If you like more, you can also use other toplevel domains like this
<link rel="canonical" href="http://www.yourdomain.com" />
<link rel="alternate" hreflang="de" href="http://www.german-keyword.de" />
<link rel="alternate" hreflang="en" href="http://www.yourdomain.com" />
Put this tags in the head of every version of your website!
Here is how it works:
Canonical tells google to use all incoming linkjuice on this page to "this specific canonical url". This includes duplicate content pages, which may exist trough struggling with GET parameters! This will drop all your duplicate content worries.
Then, see trough the "Alternate Tag" which version is good for which language and show this specific url (eg. de.yourdomain.com) in the countries SERPs.
Here a the two common sources on this topic:
http://support.google.com/webmasters/bin/answer.py?hl=de&answer=139394
http://support.google.com/webmasters/bin/answer.py?hl=en&answer=189077
How should I reference my css file (which is in the non-secure area) from a webpage in the secure area. I've considered duplicating it (moving one in to the secure area) but this seems very inefficient.
Any advice much appreciated.
(p.s. there will most likely be a few follow up questions ha ha)
You can always avoid the issue by using a relative/rooted path:
<link rel="stylesheet" href="/css/screen.css">
If you must use a full URL, I'm not sure why you can't use the https protocol (which is the correct solution), but there's one more option: don't specify a protocol at all.
<link rel="stylesheet" href="//example.com/css/screen.css">
http://paulirish.com/2010/the-protocol-relative-url/
If the browser is viewing that current page in through HTTPS, then it'll request that asset with the HTTPS protocol, otherwise it'll typically* request it with HTTP. This prevents that awful "This Page Contains Both Secure and Non-Secure Items" error message in IE, keeping all your asset requests within the same protocol.
However:
Caveat: When used on a <link> or #import for a stylesheet, IE7 and IE8 download the file twice. All other uses, however, are just fine.
So if you must specify a full URL, the best/proper way is this:
<link rel="stylesheet" href="https://example.com/css/screen.css">
There's really no alternative. Relative paths to images and resources in the CSS file itself should work just fine with either approach, and won't trigger the security error. If you need absolute URLs in the CSS file, then you can use the same trick.