Is there a method to not display and important not load the Facebook Likebox on devices with a certain screen size (for example: not on smartphones) or certain data connection (not wifi), the likebox slows down the website significantly.
So the method display:none; is no option.
Currently there's no way to (reliably) query for data connection type.
May I suggest a different approach? perhaps you could load the likebox on demand using javascript, the way techcrunch.com or enter.co do it. Those sites load the social buttons only when you hover over some placeholder images.
This way, you optimize not only for mobile screens but for all devices. If you still want, you could check the viewport size before loading the buttons, or use display:none inside a media query so the placeholder images are not shown –and the buttons can't be loaded.
Why not a simple echo based on a conditional ?
For connection you would get the users speed perhaps using a bit of code like this: http://www.emanueleferonato.com/2006/05/31/determine-connection-speed-with-php/
Then an if statement if the speed is above say 56k, output the likebox code?
For mobiles, you would do the same after getting the browsers user agent.
Related
I'm building a GWT application that looks great. At the end of the page I'd like to include a WordPress blog that I'm developing. In order to do that I want to use a com.google.gwt.user.client.ui.Frame so that an IFrame gets created, and the Wordpress just gets seamlessly embedded.
I've built this and it seems to work, although there's a problem with the size of the IFrame. I'm not sure how it's getting sized, but it's too small so that scrollbars are thrown onto it. This makes the the embedding not so seamless.
What should I be doing so that this second webiste can be seamlessly embedded into my GWT app?
The easiest solution is to make iframe as big as possible, and hope that there will be no unexpected scrollbars.
Also there is another way, if you have access to the innerDocument of iframe (if SOP doesn't stop you from doing this), you can compare its size against the size of iframe, and increase iframe height/width if necessary.
If blog is in another domain, you might try to use cross-document messaging to retrieve information about the size of document(this will not work in IE7,IE6 and you will have to put some additional JS on your blog).
Also you can include information from your blog without using iframes. You can simply pull RSS of your blog, parse it and display it in any way you like it.
The setup: I have a Blogger blog set up on a domain name as blog.mydomain.com. The main site site at mydomain.com is running Umbraco CMS.
The problem: I need to have the navigation from the CMS transported to Blogger somehow, so that making a change on the main website doesn't require the extra step of modifying the navigation inside Blogger.
Generating the navigation data on the CMS side in what ever format it needs to be (XML, unordered list, JSON, etc) is not a problem. The problem is getting the data from Umbraco to Blogger after it is generated.
I'm not yet willing to use Javascript, as this would seriously impair the website for users browsing without Javascript. (Too bad because AJAX would be a very workable solution.)
I've tossed around the idea of using an iFrame. How would this work for a navigation system including sub-menus? Creating and deleting multiple iframes is out of the picture, since I don't want to use Javascript. I could use one large iframe to allow for the sub-menus, but then it would cover content at the top of the content area, rendering it unclickable.
I'm thinking about how you could do this, but while I do - in this day-and-age javascript has become very common. Most users are going to have it, and those with it disabled really shouldn't be on the web. Is this the only reason you don't want to use javascript? Around 2% according to YDN have js disabled, and that's lower from other countries. As time goes on that 2% should get lower, I don't see that as an issue. However if you absolutely can't use javascript, I'll keep thinking. I might have an idea, I'll need to test it though.
It's not possible to use IFrame, cause of same origin policy. Both sites are on different domains, when user click menu item inside IFrame, there is no way to call parent window.
There are few ways how this can be done.
1) Javascript solution. Use json rpc, or another cross-domain calls. Load menu from your CMS and render it. Yes, this requires javsascript, but, seriously, show me the site, which does not use javascript.
2) Direct server communication.
Is it possible to perform http call from blogger ? If so, just perform http call to your CMS from Blogger, get data and render it.
3) Mixed flash/javascript solution. Flash can perform http call regardless of same origin policy. Get data with flash, use ExternalInterface to call Javascript function to render data.
There is no another way to do it. I suggest you to use javascript solution
You could build an HTML skeleton of empty ULs in Blogger (the max that you might need) to hold your navigation contents, and then link to an Umbraco-generated external stylesheet.
This stylesheet could fill those LIs with CSS generated content using the :before and :after pseudo-elements, and hiding unused LIs with CSS display: none.
An example of this is at: http://jsfiddle.net/5bXja/1/
This works in IE8+ so depending on your clients, this may-or-may-not be more widely supported than Javascript. Likely not. ;-)
I recently was requested to put together a Flash site. Since I did that, I of course need to follow up with sister site that will work with handheld devices etc.
I put a site together which looks, for example, fantastic on the Blackberry, but the resolution of an iphone is so good that the site looks microscopic. What is an elegant way to deal with these resolution disparities?
Also, I just used PHP to check the browser type and feed different pages based on that, I didn't actually make a mobile subdomain or use special mobile code.. those days are over right? Or am I committing semantic crimes by treating it like a normal-but-different website?
Thanks for everyone's input.
CSS Media Queries were specifically designed to solve this problem.
Check out the article on Responsive Web Design over at A List Apart
Example site: A List Apart CSS Media Query Example
Another great example/tutorial: http://webdesignerwall.com/tutorials/css3-media-queries
another: http://hicksdesign.co.uk/
another: http://colly.com/
Resize the width and height of this window to see what the media queries are doing. (also, view the underlying css)
I'm building an HTML5/JavaScript app that runs on the iPhone in offline mode.
I know I can selectively run JavaScript by inspecting the window.navigator.standalone property - is there some equivalent switch/selector for CSS? The extra screen space that's available when running locally means I'd like to use different CSS for running as a web page vs. running as an offline app.
There's no declarative, CSS-only way that I'm aware of (such as using a media-query).
One shortcut option might be to use the trick that people use on Android, which does not have an installable HTML5 option at all: scroll the URL bar out of view. See http://www.html5rocks.com/mobile/mobifying.html#toc-optimizations-scrolling
At least that way users get a "full-screen" appearance. You may want to couple that with a min-height on the body or containing element to make sure it actually stretches far enough to scroll the URL bar out of the way.
You can use a cache manifest and provide a completely different CSS when viewing offline (under FALLBACK): http://dev.opera.com/articles/view/offline-applications-html5-appcache/
I have a page with 20 articles, and for each article, I have a Facebook Like Button, implemented using the tag.
Because of this, my site is greatly slowed down as Firefox makes a query in the background for each of the like button.
Is there anything I can do to reduce this load?
In my experience, all the extra IFRAMES are actually faster than using the JavaScript SDK, even though the Like icons are supposed to load asynchonously. I have a page with about 18 like buttons on it, and at least the IFRAME approach doesn't result in a perceived slowdown for users like the JS version does - the only downside is that the Like buttons "pop" into the page a little late in IFRAMES.
I assume you're using iframe to display your like buttons. Performance is the downside of using iframes. If you've got 20 iframes, then it's equivalent to loading 20 web pages (with 20 independent http requests). As browsers have connection limits per domain, it can take a while for this many iframes to load. This is especially true in older browsers, where connection limit is only 2 per domain, which means that only 2 iframes can load at a time. iframe can also have the negative side effect of blocking other downloads, which makes the problem even worse. You can read all about iframe performance problems here:
http://www.stevesouders.com/blog/2009/06/03/using-iframes-sparingly/
If possible, you may want to consider using xfbml like button instead of iframe. Unfortunately, this means that you'll need to load Facebook's JavaScript SDK, but with 20 like buttons, you should see an overall performance boost.
As an alternative, if you're not keen on the idea of xfbml, you could try a service like OpenLike: http://openlike.org/
From their docs:
A widget is created by first loading the OpenLike javascript and then calling OPENLIKE.Widget(). Multiple widgets can be embedded in the same page, each with different options.
I ended up going with something similar to this solution Lots of XFBML Facebook Like buttons are slow? with JQuery Sonar. It seems to do the trick for me. I'd prefer a single call that loads all the buttons but it's outside of my control.
If I had more time what I'd do is use the facebook API to get the count and make my own buttons (perhaps load the real button on hover if i wanted their functionality but iirc you can just call the "share" function directly). I don't currently have time to massage facebook that much so this is a sorta makeshift hack that I don't think has too many downsides and it seems to be used by a number of different sites.