I've integrated this nice Facebook-Button to my WordPress site via iframe. Although I care for cross-browser-compatibility plus the fact I could not influence the iframe content in regular ways I'm wondering why this quirks when viewed in IE6.
Could I've done something wrong anyway or is it conceivable stuff quirks by default and Facebook doesn't care about that?
Facebook does officially not support IE 6 any more.
(And I’m glad about that. Just wondering why you still care?)
Related
I am going insane with this. It used to just work! I'm a programmer but not up to date with all this modern languages stuff and have no desire to learn it - too darn old, just want an easy life.
Okay, so here's the thing... I used to have these "like boxes" on my websites. Then they stopped working. I looked in the dev docs and fixed the absolute URL and they worked ok on IE browsers but not on Chrome.
It looks like I need an App Id.
So I created an App Id on a test website - I have no idea what it is or why I need one. All I want to do is show on the website it has n likes and the button for Facebook lovers to like it too.
But do I need to create an App Id for every single clients website? How do other CMS systems handle it? My sites are not html 5 - I'd be happy with just an iframe solution.
I'm not a fan of Facebook at all, and this is driving me further away. I'm willing to be dragged back but all I see is lots of overly complex code to achieve nothing really useful.
You can do whatever you want with your app ID, but if you use the same one for all your sites, you won't be able to separate those in your "Insights"
https://www.facebook.com/insights/
I wanted to see if anyone else had ever had an issue with Mobile Safari or Chrome causing web pages to suddenly spit out a ton of garbage.
The issue occurs when I visit the site & refresh multiple times. Suddenly, none of the content renders correctly, but instead looks more like the type of glyphs you'd see in Microsoft Word.
Has anyone ever seen this before and, if so, how did you resolve the problem?
I have seen it on iPhone and Android. On iPhone I suspect its due to the interruption during the page load (getting kCFURLErrorCancelled on the didFailLoadWithError method). Though I am still looking to confirm this issue and still looking for a solution ...
You should check the character set of the HTML page. Bases on your language or the special characters used in the page, you should use the apt charset. You can learn more about charsets here
http://www.w3schools.com/tags/ref_charactersets.asp
http://en.wikipedia.org/wiki/Character_encodings_in_HTML
http://en.wikipedia.org/wiki/UTF-8
It is really difficult to tell anything from what you have posted. You should check the meta tags of your page. I would suggest you validate the html source and css of the page here .
Please forgive me if this answer is somewhere else on this site or online. If it is, I sure haven't found it in the past several days of searching.
What I am hoping to find is an "accurate" method of detecting a browser and redirecting to a simple, static page if not a recent browser.
The samples I have found until now often have not provided an accurate representation of the actual browser being used. For instance:
When testing with Navigator 9, I'll get a message that I'm using Firefox 2
When testing with Maxthon 3, it reports I'm using IE 9.
My site displays correctly in all the current browsers I've been testing it with. But I wish I could have a basic static page for those .01% who still are using an old browser for whatever reason. They could still get some basic information from my site, as well as encouraged to update to a more current browser.
If anyone has any useful suggestions, I'd greatly appreciate them.
Thanks so much.
Cheers,
David
Browser detection is never perfect, for a variery of reasons. If you are using jQuery, you should look into jQuery.browser.
I'd try to detect the browser on the server side and do an HTTP redirect if the browser is something non-standard. Most decent frameworks have functionality to detect the browser from the user agent string. Again, this is not perfect, mainly because of the data browsers report. Also, if Maxthon reports it's IE, that's because it is based on IE and therefore the layout engine should be the same.
So you either
support a small number of browsers and cater for their quirks, sending all other browsers to a basic page (this sucks for future versions of browsers because they might be standards-compliant but they will still display your very basic page), or
you have a standards-compliant page for all browsers and then you define alternatives for the ones that give you problems.
I'd go for the second option. It usually all boils down to one version for all browsers, and a number of hacks for various versions of IE. Also, remember to avoid padding in your CSS and use margins instead.
In the end, you probably shouldn't be testing for browsers and version numbers, but supported features. Try using Modernizr.
The $.browser property is deprecated in jQuery 1.3. On jQuery support site, they strongly recommend to use the detection feature (JQuery.support) instead of the jQuery.browser property.
Actually, this has been answered already in another question, please check here How can you detect the version of a browser?
This might sound like a silly question, but yesterday none of our sites would load. After contacting the hosting company they said that
In this instance, it would appear that your site is hanging waiting for a response from an external component / website (looking at your code, I see references to Facebook, Google and online apps at a glance).
We've never had this problem before and the sites have been using the social plugins for months so I wondered if anybody else experienced this problem yesterday?
Thanks
Without knowing the details, I can tell you that when you load Javascript via <script></script> tags the browser waits for the request to finish before moving on. So, if you load JS files in the <head></head> section, nothing will render on-screen until they load successfully. 404s here will kill you, as will slow connections.
If you have in-line JS, it's best to put it at the very bottom of your <body></body> section so that it does not interrupt browser rendering. Do this for JS files in your <head></head> section if your code architecture allows it.
Just a random stab in the dark but I wonder if this was related in any way to the anonymous threats on Facebook. I have experienced similar problems before with a twitter plugin, it could take a few seconds for the plugin to ping back the tweets and the rest of the page was hanging while twitter was doing their thing.
To ensure this doesn't happen again you could call your social plugin's on page load if its a viable solution. At the end of the day do you want your page load time to depend on other services outside of your control or not?
edit: #Jason McClellan 's answer is spot on. I believe the combo of out answers sort out your question. I Never include script in the head if I don't control the resource! That can indefinitely hang your page.
edit2: Don't know why I'm getting down rated for this answer was just trying to relate it to an experience of mine. I'm not extremely experienced with Facebook plugins but when I was noticing an issue with my twitter plugin, I did exactly what #Jason McClellan has said with his answer to make sure that all your html gets rendered before the scripts are even requested, then ensured that the page could display correctly with or without the twitter content so the user experience was not dependant on an external resource. The twitter plugin I was using had an initiation function which I had to call to fire up the script. The simplest way to call this would be with:
<body onload='init()'>
if you have another script you are loading with the page you could use something along the lines of
window.onload = function() {
init();
}
from within your external script.
Sorry I can't give an answer specific to the Facebook plugin. Maybe someone with more experience in the Facebook plugins could elaborate in the comments :D
edit3: also this community based tool suggests that quiet a few people where seeing a bit of facebook downtime when you experienced it - Facebook status at DownRightNow
edit4: I dont have the "Privelages" to comment on Jason's q as im pretty new here ... but in answer to your comment there, the stuff in the head that you describe is what loads in the schema for facebook mark-up language (fbml) , so a mark-up language like html, but geared up for you to use the facebook api. So you can do stuff like:
<fb:comments xid="titans_comments" canpost="true" candelete="false" returnurl="http://apps.facebook.com/myapp/titans/">
<fb:title>Talk about the Titans</fb:title>
</fb:comments>
To wack some comments straight into your page - fbml developers guide
Your comment there also suggests you are not including a script for your page to load so it renders our previous answers not as important, you need to include the fbml stuff in the head before you use fbml in your page so don't move it :D
but #jason McClellan's answer is something that everyone should do on their project (unless there is a reason not to) as it allows for the user to see something before the browser fires off requests for the scripts. At the end of the day we're in this game to make pretty stuff for our users!
Good luck
I have a Flash app at URL-A. I have a new non Flash version, that only works in modern browsers at URL-B. I can redirect all visitors from URL-A to URL-B with .htaccess or PHP but I wont know what browser they have in order to determine if I need to redirect or not.
So I am not sure what the best way to go about this is.
Basically if you are using IE8+, FF, Chrome, Safar, Opera I want you to go to URL-B. If you are using IE7- I want you to go to URL-A
Whats the best way to do this?
If you have no problem with using a small PHP library, look at the answer to this question and do a header("Location:url") redirect depending on which result you get.
If you'd rather use a .htaccess file, you could parse the USER_AGENT as shown in this question (it's aimed at mobile browsers but doesn't really matter). The PHP solution is much more convenient though.