Posted on March 18th, 2009 by Paul Campbell
Without a doubt, the biggest impact my CSS world is the float clearing powers of overflow. After struggling so many times with solutions to avoid mark-up based clearing (i.e. a span with a clear class), and admittedly finding some success with the Clearfix solution. I found this article by Sitepoint. Devastatingly simple, easy to implement, and I have followed this, in most cases, ever since.
The solution however isn’t without it’s own problems - scrollbars often appear on the wrapping DIVs. Particularly if you’re tightly wrapping a selection of links. I.e. a menu bar. A fix came about when a work compadré, Sam Loomes, recently made a brilliantly simple observation, that maybe the fix would work by setting overflow to hidden. God damn, it worked, scrollbars are banished and the clearing still occurs!
So here it is, CSS overflow fix in all it’s, um, glory. With no semantic or layout implications. Enjoy.
.wrapper {
overflow: hidden;
}
Posted on August 15th, 2008 by Paul Campbell
Our approach to Flash SEO (and accessibility)
There’s been alot of press lately regarding the new found viability of Flash and search indexing. Whether the improvements in the Flash player quantify to leaps in plug-in SEO or nothing more than than a puff in the wind.
In my opinion there’s little change in Flash SEO capabilities. Google have been indexing Flash files for sometime, and there’s been little formal evidence to suggest that a SWF can alter your search result position in anyway.
During a recent in-house project we came across this very issue and attempted to create our own style of Flash indexing for the site. After recent review it appears to be working brilliantly and has sucessfully managed to promote the indexing of textual content for each Flash page uniquely within Google search results.
The technical solution was a combination of Apache mod_rewrite, PHP (SimpleXML), SWFAddress (for SWFObject) and some bespoke JavaScript holding it all together. With the Flash site popualted via an XML document and utilizing SWFAddress to create a historical (back button) record of pages visited within the SWF. It was a case of converting the internal SWFAddress URIs (that use a standard hash technique that all AJAX based apps use) to a standard URL and preventing 404’s by mod_rewrite. Then once a URI is registered on the server, it serves up the index HTML with a parsed text-only version of the content, promoting indexing for search bots, and converting a standard URI to a hashed version via JavaScript (in the case that JS was activated and Flash was installed).
Whilst this approach may seem longwinded, it allowed us to generate an accessible, indexable site that offered the correct content delivery for relevant client platform (HTML or Flash). Improving the search ratings of the site and promoting deeplinked Flash pages.
Start Creative currently operates this system on their agency portfolio site, and I for one, am pretty proud of the achievement. Examples of the indexable links:
http://www.startcreative.co.uk/adidas/hub/, http://www.startcreative.co.uk/bbc/case_02_dsdWebsite/
Posted on April 10th, 2008 by Paul Campbell
To the future of applications
So yesterday I attended the Adobe onAIR tour at The Brewery in London’s east-end. And what a pleasant surprise it was as well. After being a little disappointed with the Colin Moock session a few weeks ago I wasn’t sure what to expect but the AIR team definitely turned up to impress.
Daniel Dura and Kevin Hoyt both made really interesting presentations about the flexibility of the AIR development environment and underlying interface. Particularly ion regards to integrating HTML and Javascript.
Dion Alamer from Ajaxian.com made a a great talk about Google gears and the 3rd party technologies you’ll be able to utilize within AIR. Pointing out the fact that this technology embraces the existing, rather than developers having to recreate the wheel.
Lee Brimelow finished off the show with some great mini applications demoing some key features of the app and supplying us all with a much needed laugh at the end of a long day.
Looking at the technology it’s definetely got some serious legs. At the very least the opportunity for web developers to create native applications without having to worry about learning the formalities of standard application development is great. The main sell of AIR has to be around the integrated web/desktop features. At initial review, the ability to drag-and-drop web data from your browser is brilliant but the possibilities that this opens up is just unimaginable. In a digital world where Google is taking over with online applications and slowly trying to bring your desktop to the web. An application that brings the web into your desktop and vice-versa is not necessarily in competition, but quite simply the personification of Marshall McLuhans “Global Village”.
I for one can’t wait to get my teeth stuck into developing some AIR applications.
http://www.adobe.com/go/air http://onair.adobe.com/
Posted on November 27th, 2007 by Paul Campbell
A new fix for IEs lack of inline PNG transparency support
At the moment it seems our design team just keeps churning out sites that need PNG’s all over the place. We always try to use GIF’s where possible, but when those partially transparent, gradient-based nightmare assets pop-up, a GIF just doesn’t cut the mustard.
Until recently we’d been using Twin Helix’s solution by Angus Turnbull which, in general, was a great (and the only really viable) fix for most projects. That was until we discovered a major memory issue when using this in combination with the Google Maps API. Researching the issue (using Kevin Langdon’s immensely useful ServiceCapture) revealed pages with more than a healthy amount of PNGs, the .htc approach sucked-up some serious memory. The cause was not the script itself, but a result of executing the call via behavior(). This not only executes the script in an arbitrary order, but makes additional HTTP requests for the .htc file on each applicable element!
On a page with potentially dozens of PNG’s, IE was making too many HTTP requests, running multiple parallel processes and falling on it’s ass (which admittedly it does do oh-so-well). Consequently we decided it was time to write our own fix, in the guise of a plug-in for the wonderful jQuery framework.
The plug-in is essentially based on the original Twin Helix fix but focusing on reducing processes, speeding-up the render time and ultimately killing all those unneeded HTTP requests. At it’s most basic, the fix can be applied to elements as such:
$("img").pngfix();
Of course you’ll need to implement jQuery along-side this plug-in, but that’s a pretty simple affair. For full technical documentation, please go to the PNG Fix project page.
Download the Javascript source file (jquery.pngfix.js 8kb)