I am looking for a site for somebody, and fixing errors as I find them.
There is no Favicon.. that is ok, I can fix that.
My question is, do browsers (or certain browsers, Chrome in this case) request favicon.ico as soon as they load a site.. or maybe on check that there is no alternative icon path mentioned in the source.. irrespective of whether "favicon.ico" is actually mentioned in the page source?
That was the original behaviour, yes. /favicon.ico was an implicitly present file which (some) browsers would check for. Only later did that actually morph into a proper standard with <meta> tags, arbitrary file names and image formats other than .ico.
Related
My website is hosted by 000webhostapp.com. It is working in all browsers (Moz, Opera and mobile) except desktop chrome. There is no error in W3C validator and all path and links are correctly written. What maybe a reason?
in Chrome desktop
DT(F12) console screen
The culprit here is AdBlock. More precisely, EasyList filter list that is applied to AdBlock's filter sets by default.
There's a following rule inside that set which says: Block any resource where URL matches to /adx, but not for domains adx.uk.com or adx.wowfi.com.
/adx.$domain=~adx.uk.com|~adx.wowfi.com
In your case it matches a part of your domain name: http://adx.000webhostapp.com/css/normalize.css
You can find every blocked resource on AdBlock tab in your browser's Developer Tools.
How to solve this?
The best way to solve this is to contact EasyList authors and inform them about incorrectly blocked content. According to their website, the preferred way is to write on their forum (registration is not required).
Another way is to serve every resource (styles, scripts, images) from different domain that will not get caught up in the filter.
Yet another way, tho not recommended, is to ignore this issue or entirely change your domain name.
I looked into it and it seems the problem is adblock, I tried disabling my adblock on chrome and it worked just fine so maybe look into why adblock is stopping you from loading your css or just put in something that tells the user to disable the adblock.
More information here: https://www.keycdn.com/support/how-to-solve-err-blocked-by-client/
I have noticed that HTML5 Boilerplate and dev websites like css-tricks.com use only apple-touch-icon as any reference to favicon, and that image is indeed displayed in a browser. I was not following this topic for a while and am confused to how this works. Is it safe to now only include a touch-icon and will it be displayed in various browsers?
A favicon.ico file is used by the browser automatically if it's in the root directly of your page/app.
If you want to add a favicon in a different format (e.g. png), of you want to add it from another source (e.g. a subdirectory like /img) or if you want to make the browser load a new version of the file (e.g. favicon.ico?v=2) you use the link tag.
More info here:
Necessary to add link tag for favicon.ico?
I have a wordpress site here http://itrain.com.my/v3/ as my Home Page
I am wondering why it is not displaying well in Firefox?
Anyone who is good in css?
By the way, try to look at the subpages http://www.itrain.com.my/v3/index.php/about-us/
it display well.
I am really wondering why does it happening.
Any can help me? Any suggestion, recommendations?
I think problem is with URL.
It work http://www.itrain.com.my/v3/ but doesnt work on http://itrain.com.my/v3/
Set on your server redirection (301) from non-www URL to www URL.
I would wager you have the font installed on your local machine. I don't see it on any browser. Instead, I get two 404 errors.
In other words: please make sure the font files are available at the locations their respective locations: http://www.itrain.com.my/v3/wp-content/themes/itrain/img/fonts/big_noodle_titling-webfont.woff and http://www.itrain.com.my/v3/wp-content/themes/itrain/img/fonts/bebas__-webfont.woff.
[EDIT]
I've just looked at the fonts directory listing on your site. The ttf and eot versionf of your fonts are available, the woff and svg are listed, but result in a 404 error. Furthermore, the ttf version (downloaded instead of woff in Firefox, after getting a 404) seems to generate an empty HTTP response.
So... Make sure the fonts are there, make sure they have proper privileges set (like 0644). I can't see any other issues than the font files themselves as the CSS appears to be correct.
[EDIT 2]
#kubedan provides a great tip that seems to fit your concern about the htaccess: the domain the fonts are downloaded from is always preceded with www. Firefox will refuse to download such content, you need to use the same domain.
I have declared AddType application/x-font-woff woffbut chromium still always give me the message Resource interpreted as Font but transferred with MIME type application/octet-stream. What is going on here, it seems to be a rather common problem. This is Chrome version 14 by the way.
This was actually a legitimate bug in chrome at the time of posting, not sure if it still exists and can't find the relevant link to chrome bug list. If anyone is interested that'd be the first place to look.
Old question but a possible answer for future visitors:
Chrome caches the heck out of things - even when you change the header from the server, Chrome may still load the resource from it's cache. So clear the cache and if necessary, check the headers from a realtime web-checking service.
Is anyone aware of whether it is problematic to use protocol relative URLs for an image source to prevent mixed content security warnings.
For example linking an image like:
<img src="//domain.com/img.jpg" />
instead of:
<img src="http://domain.com/img.jpg" />
or
<img src="https//domain.com/img.jpg" />
In my testing i've not seen anything to suggest this is wrong but i'm not sure if it has edge cases where it will create problems.
EDIT i've seen it throw errors when using PHP's getimagesize function.
Found an interesting gotcha for the use of protocol relative URLs:
You have to be careful to only use
this syntax in pages destined for
browsers. If you put it in an email,
there will be no base page URL to use
in resolving the relative URL. In
Outlook at least, this URL will be
interpreted as a Windows network file,
not what you intended.
from here
Essentially though there are no valid reasons why this shouldn't work as long as the request is made by a browser and not an external email client.
more info from here:
A relative URL without a scheme (http:
or https:) is valid, per RTF 3986:
Section 4.2. If a client chokes on it,
then it's the client's fault because
they're not complying with the URI
syntax specified in the RFC.
Your example is valid and should work.
I've used that relative URL method
myself on heavily trafficked sites and
have had zero complaints. Also, we
test our sites in Firefox, Safari,
IE6, IE7 and Opera. These browsers all
understand that URL format
IE 7 and IE 8 will download stylesheets twice if you're using a protocol-relative URL. That won't affect you if you only use it "for an image source", but just in case.
The following should be considered when using Protocol-Relative URLs:
1) All modern browsers support this feature.
2) We have to be sure that the requested resource is accessible over both HTTP and HTTPS. If HTTP redirects to HTTPS it is fine, but here the load time will take a little longer than if the request was made directly to the HTTPS.
3) Internet Explorer 6 does not support this feature.
4) Internet Explorer 7 and 8 support the feature, but they will download a stylesheet twice if protocol-relative URLs are used for the css files.