Chrome’s extension manager is pretty sweet. You can install plugins (called extensions in Chrome) without restarting your browser and they go in effect right away.
This may save someone minutes of searching but the best Cookie management plugin for Chrome is Edit This Cookie. It handles the basics of viewing, removing, and deleting cookies without any additional bloat. And the UI isn’t bad either.
One caveat is that if you block a cookie from a site and later want to unblock it, you have to go to the options panel. Had to spend minutes googling that as well.
So the new Firefox 3 that was released last week is awesome. It’s much faster, doesn’t seem to hog memory as much as the old one, and has a completely revamped bookmarks system which I enjoy. Mozilla reached it’s goal of getting in the Guinness World Records for the most downloaded application in a single day (8 million) and if you haven’t downloaded it yet I suggest you try it now. They also fixed a ton of bugs including the really annoying Mac flash overlay issue on transparent CSS backgrounds. Now if only FF3 was an auto-update…
Display and functionality-wise, all my pages seem to display exactly the same except for two issues:
Update: The issue seems to be caused when having the new Firebug 1.2.0b3 with Firefox (and possibly having the YSlow addon, too.) If you disable Firebug the errors go away and all functionality is restored. I hope this issue gets fixed soon! If you found this entry through a search engine and are also experiencing the issues please post here so we can see how big this issue is.
Generally though, FF3 is definitely worth the upgrade and besides the two issues above I experienced on my own project, I see no issue on the regular sites I visit.
APIs tend to be very arbitrary things. Even a well-documented and executed API can differ drastically from another of the same quality in the same category. For a current project I had to integrating YouTube’s API into our system (for searching and embedding videos) and found it a breeze. Using their documentation I found that I could get the data any way I want – atom, rss, json, json-p, etc. Not only this, but everything from their videos, comments, and related media was very well organized and layed-out (who would have though less of something from the guys at Google). In actuality it wasn’t the smart minds at Google that thought up this efficient data structure – they were just following the creative-commons licensed OpenSearch specification created by Amazon’s A9. A format that is used by a lot of companies from Amazon to Firefox to Wikipedia.
A week later my new project was to integrate the API from another large video site. Their API, while perfectly fine for a custom solution was as arbitrary as any other – which got me thinking: “Wouldn’t it be great if this company had also integrated OpenSearch?” This would have made implementing them into our system effortless using my existing code-base instead of a full day extra work an additional code. Their data structure is already similar and all it would require would be some reordering and renaming of nodes (obviously a little bit more work than that, but not much!)
As the Web matures, standards are becoming more and more important and unless your product has a specific reason for having it’s own proprietary API (and there may be a good reason but I didn’t see one in this case), you may find you’ll lose business or popularity to others that are more “open”. In most cases, a company would have happily used an open standard or format, saving more work for themselves and developers working with their system – they just weren’t aware that one existed. So this is my post to you about open search. Read about it, embrace it, and let’s use open formats before creating our own!
I’ve been doing a lot of remote iframe work as of late and while creating some functionality that submits a form to a dynamically generated iframe I quickly found that in IE6/7 you cannot target an iframe created with
document.createElement('iframe');. You must instead use
innerHTML to write out the iframe inside another element.
Oh IE, we will never understand you!
Update: Max commented that you can indeed use document.createEelement and still target iframes in IE, you just need to create them in this way
document.createElement('<iframe name="iframeName">');. Still über quirky but slightly better than the innerHTML approach. Kudos Max!
If you’re like me, and you’re constantly using
document.cookie to check your cookie settings in Firebug Console – life just got a little bit easier with a Firebug Extension by Jan Odvarko called Firecookie that let’s you view and manage cookies. Sure their’s plenty of cookie plugin-ins for Firefox and the built-in cookie manager is fine, but for the speed of having a tab right there in your Firebug console it’s a great time-saver.
Another great feature is that whenever a cookie value changes it’s logged in your console – a feature especially good for troubleshooting (but perhaps an extra option for turning that off would be nice.) I like seeing what kind of values the sites I visit are using.
Jan has also wrote up a tutorial on extending the Firebug console with your own creations – this is something I’m definitely looking forward to experimenting with. I also look froward to seeing other creative addons. Nothing beats Yahoo’s YSlow Firebug extension, though. Something I’ll have to write more about in a future entry.