An Overview of Firefox’s Coming Developer Tools
Using the 3-D Page Inspector tool, coming soon to a Firefox near you.
Firefox is poised to deliver some new tools for web developers. When Firefox 10 is released in early 2012 it will add HTML and CSS inspectors designed to help web developers inspect and debug their code. Later releases will add more features, like a 3-D page inspector and even a built-in code editor.
Eventually Mozilla believes the built-in tools will replace the popular Firebug extension for most users, though it will likely be some time before that happens. In the meantime, if you’d like to see the new built-in developer panel in action, grab a copy of the Nightly builds, which all have the new tools in various stages of completion.
It’s worth noting from the start that these tools are not intended to replace the popular Firebug extension for those that need Firebug’s power user features. As Mozilla’s Kevin Dangoor wrote when the project was first announced: “we think Firebug is awesome… that’s why we invest so heavily in it already, more so than for any other add-on. We also want to explore new approaches to developer tools.” In other words devoted Firebug fans need not fret, the popular extension isn’t going away. The coming built-in developer tools are designed to supplement, not replace Firebug for the power user.
That said, the new developer tools will provide many of the basic features web developers require and will likely make Firebug unnecessary for many users.
Although they aren’t yet nicely integrated into a single panel like Firebug offers, by the time Firefox 12 hits prime time the browser will offer a web console, an element inspector with HTML and CSS info, Scratchpad for JavaScript development, a CSS style editor and an error console. Firefox’s view source will also add line numbers, closing a seven-year-old feature request.
The newest of these features is the page element inspector, which is now available in the beta channel. The basic layout of Firefox’s element inspector is a little different than what you’ll find in Chrome or Opera.
When you select “inspect element” Firefox will bring up a breadcrumb-style menu bar at the bottom of the page. To see the actual HTML or CSS applied to that element you need to click the corresponding buttons in the toolbar (or use the keyboard shortcuts). It’s an unusual design decision given that inspecting the element generally means seeing the HTML (at least that’s how every other browser does it), and it means there’s an extra click necessary to get to the same information that’s just one click away in WebKit and Opera.
The element inspector also dims out everything but the currently selected element — the visual opposite of what you’ll find in other browser’s inspectors, which color the currently selected element and leave the rest of the page as is. It’s not a deal breaker by any means, but it can be somewhat jarring when you’re used to opposite look.
On the plus side Mozilla has started work that will integrate the very handy Tilt add-on, which we reviewed a while back, into the inspect panel. The integrated Tilt option is only available in the Nightly channel at the moment, though of course you can just install the Tilt add-on if you want to use it today.
Look for the 3D inspector tools to arrive in Firefox 12 if all goes according to plan. Mozilla also plans to add a themeable Code Editor (so you can edit CSS files, or write JavaScript right in the browser).
While Firefox’s new developer tools are improving (and will be much more useful when the element inspector arrives in Firefox 10), there are still plenty of reasons to prefer Firebug or the WebKit tools. For example, if you open Firefox’s HTML inspector, style inspector and web console all at the same time there’s almost no screen space left for the actual page content. Firebug, WebKit and Opera all save considerable screen real estate by consolidating their tools into a single tabbed panel.
For more details on the new Page Inspector coming in Firefox 10, here’s Mozilla’s screencast overview:
Building Better Single-Page Web Apps
Single-page, application-style websites offer web developers a way to replicate the user experience of native apps, particularly on mobile devices. Indeed, the application design model — that is, a single webpage that never needs to refresh or reload — is the basis for some of the web’s most popular sites like Facebook and Twitter.
But such app-based sites often break fundamental tenets of the web, eschewing HTML source for JavaScript, breaking the browser’s back button and removing the ability to link deep into the application. Some of these problems are addressed by standards like the HTML5 History API, which allows applications to update the URL bar without refreshing the page, but not every app bothers to take advantage of such recent developments.
The potential problems single-page apps can cause are not, however, sufficient reason to avoid them, argues Mozilla Developer Evangelist Christian Heilmann. Done responsibly and in keeping with the best practices of the web, the single-page app can be part of the future of the web, writes Heilmann.
Among the benefits of single-page apps are speed gains — stripping away the HTML means there’s very little to load initially and subsequent data loads can be done in very small increments, which makes for very fast apps. With the rise of web apps targeting mobile devices the speed advantages make single-page apps appealing to developers. Indeed, Heilmann believes “single page apps … are necessary for the web to be an apps platform.”
Naturally there will be problems with the rise of apps. “We have to battle two main issues,” writes Heilmann, “old conditioning of users and sloppy development for the sake of doing something ‘new’.”
In other words the danger isn’t the single-page concept itself, which, if done right, will yield an “app” that also has all the benefits of the web — deep linking, bookmarking, and indexing. It’s the latter problem Heilmann mentions, one that’s neatly satirized by sites like Hipstergrammers, that causes many developers concern: new just for the sake of new.
Heilmann’s post does a great job of cutting through the hype behind single page apps and presenting them for what they are — another tool with both positive and negative trade offs. Be sure to read through the whole article which offers a great list of potential problems and how to avoid them.
Why Google Continues to Fund Firefox
Just before the holiday weekend Mozilla announced that it had renewed its long-standing search revenue agreement with Google, which will reportedly net Mozilla $ 300 million a year (as part of a three-year contract). The renewed contract comprises the bulk of Mozilla’s funding and is unquestionably a good deal for Mozilla. What’s less immediately clear is why Google — which now has its own Chrome browser — would want to continue the deal.
Indeed, why fund the competition? M.G. Siegler speculates (based on AllThingsD’s report that there was a bidding war over Mozilla) that Google is willing to spend that kind of money just to keep Microsoft from starting a partnership with Mozilla.
That’s one theory. But it may well be that the truth is much more mundane. It may be that Mozilla is just one of a number of payouts that Google makes to help drive ad sales.
In fact, as Mozilla’s Asa Dotzler points out, Google pays out roughly 24 percent of its ad revenues to drive more traffic to its ads:
Not all traffic to Google ads is “organic” though. To help drive ad sales, Google pays for traffic to their ads. They paid out $ 2.21 billion, or 24% of their ad revenues in “Traffic Acquisition Costs”. That money goes to revenue shares with their AdSense partners and to “distribution partners” — presumably browser makers, PC OEMs, and mobile OEMs and operators.
As Dotzler goes on to point out Google pays out similar money to Opera and Apple, which both use Google as the default search engine in their respective browsers — again, driving eyeballs to Google ads. Dotzler’s point being that the Google-Mozilla deal is not a charitable arrangement, but a business deal built around driving eyeballs to Google ads. Firefox currently holds roughly 25 percent of the global browser market, which is certainly a healthy number of eyeballs..
Of course it’s possible that other factors may also influence Google’s decisions. Google Chrome developer Peter Kasting says that Google’s motivation for building Chrome is to “make the web advance as much and as quickly as possible.” That means, according to Kasting, that “it’s completely irrelevant to this goal whether Chrome actually gains tons of users or whether instead the web advances because the other browser vendors step up their game and produce far better browsers.” In other words, funding Firefox helps to further the same goal that drove the company to build Chrome in the first place — advancing the web.
That would be somewhat easier to swallow if other parts of the Google machine didn’t build so many experiments that only work in Chrome.
Regardless of Google’s motivation for building Chrome, or for funding Mozilla, both moves have proved great news for users. And in the end the precise motivation behind the Google-Mozilla deal are something only tech writers really care about. Users care about speed and there’s no question that Chrome has helped spawned a renaissance among web browsers and helped put speed back on top of every browser makers’ to-do list (the drive to adopt HTML5 has also done wonders to improve the average user’s experience on the web).
For most users the Mozilla-Google deal just means that there will continue to be a number of browsers to choose from and a number of browsers to help keep pushing the web, and each other, forward.
Support Versus Optimization: Dealing With Mobile Web Browsers
Just a few of the many screens on the web
Last time we sent you over to Brad Frost’s blog it was for a slideshow about building a future-friendly web. Now Frost is back with some more tips for web developers in a post entitled Support vs Optimization, which tackles the thorny subject of what to do about the wide range of mobile browsers on the web.
As Frost points out the mobile world is more than just the WebKit-based iOS and Android browsers that often grab all the headlines. In fact the most widely used mobile browser is not even a WebKit browser (it’s Opera) and there are dozens of other mobile browsers out there as well. And, as the tablet market begins to expand beyond the iPad, there will likely be dozens more coming in the near future.
Faced with the diversity of the mobile browser market developers can either stick their heads in the sand and develop exclusively for WebKit browsers, or, as Frost suggests, we can be more considerate to other browsers. It can seem daunting to support dozens of mobile browsers, but if you aren’t up to the challenge of a few mobile browsers now what are you going to do when you need to support car dashboards, refrigerators, televisions and toasters, all with dozens of varying browsers? (For a more far-future look, check out Scott Jenson’s The Coming Zombie Apocalypse).
The solution, according to Frost, is to recognize the difference between supporting a browser and optimizing specifically for it.
The typical argument against supporting older BlackBerry browsers or Nokia’s WebKit fork, for example, is that these browsers don’t support nearly the number of features that iOS and Android browser’s offer. While that’s true, as with most things on the web, it doesn’t have to be an either/or choice. It can actually be both. That’s what Frost means be the difference between support and optimization:
You don’t have to treat these browsers as equals to iOS and Android and no one is recommending that we have to serve up a crappy WAP site to the best smartphones on the market. It’s just about being more considerate and giving these people who want to interact with your site a functional experience. That requires removing comfortable assumptions about support and accounting for different use cases. There are ways to support lesser platforms while still optimizing for the best of the best.
For some practical advice on how you can take a more supportive approach to the wide range of mobile browsers on the market, head over to Frost’s site and read through the post. Be sure to check out the links to the various mobile emulators and brush up on the ideas behind progressive enhancement.
It’s a big web out there, with dozens of browsers and an ever-increasing number of devices connecting to it. If you want your site to be part of the future it’s going to have to work everywhere — perhaps not perfectly optimized, but at least working.
[Photo by Jeremy Keith/Flickr/CC]
Support Versus Optimization: Dealing With Mobile Web Browsers
Just a few of the many screens on the web
Last time we sent you over to Brad Frost’s blog it was for a slideshow about building a future-friendly web. Now Frost is back with some more tips for web developers in a post entitled Support vs Optimization, which tackles the thorny subject of what to do about the wide range of mobile browsers on the web.
As Frost points out the mobile world is more than just the WebKit-based iOS and Android browsers that often grab all the headlines. In fact the most widely used mobile browser is not even a WebKit browser (it’s Opera) and there are dozens of other mobile browsers out there as well. And, as the tablet market begins to expand beyond the iPad, there will likely be dozens more coming in the near future.
Faced with the diversity of the mobile browser market developers can either stick their heads in the sand and develop exclusively for WebKit browsers, or, as Frost suggests, we can be more considerate to other browsers. It can seem daunting to support dozens of mobile browsers, but if you aren’t up to the challenge of a few mobile browsers now what are you going to do when you need to support car dashboards, refrigerators, televisions and toasters, all with dozens of varying browsers? (For a more far-future look, check out Scott Jenson’s The Coming Zombie Apocalypse).
The solution, according to Frost, is to recognize the difference between supporting a browser and optimizing specifically for it.
The typical argument against supporting older BlackBerry browsers or Nokia’s WebKit fork, for example, is that these browsers don’t support nearly the number of features that iOS and Android browser’s offer. While that’s true, as with most things on the web, it doesn’t have to be an either/or choice. It can actually be both. That’s what Frost means be the difference between support and optimization:
You don’t have to treat these browsers as equals to iOS and Android and no one is recommending that we have to serve up a crappy WAP site to the best smartphones on the market. It’s just about being more considerate and giving these people who want to interact with your site a functional experience. That requires removing comfortable assumptions about support and accounting for different use cases. There are ways to support lesser platforms while still optimizing for the best of the best.
For some practical advice on how you can take a more supportive approach to the wide range of mobile browsers on the market, head over to Frost’s site and read through the post. Be sure to check out the links to the various mobile emulators and brush up on the ideas behind progressive enhancement.
It’s a big web out there, with dozens of browsers and an ever-increasing number of devices connecting to it. If you want your site to be part of the future it’s going to have to work everywhere — perhaps not perfectly optimized, but at least working.
[Photo by Jeremy Keith/Flickr/CC]
Mozilla Unleashes Faster, Smaller Firefox 9
Mozilla has released Firefox 9, which brings speed improvements and uses less memory than previous releases. In fact, this release effectively puts Firefox back on a level playing field with Google Chrome when it comes to speed.
If you’d like to try out Firefox 9, head on over to the Mozilla downloads page. If you’re already using Firefox you’ll be automatically updated to version 9.
The big news in this release is under the hood where Firefox now supports what’s known as Type Inference. Type Inference is a new feature for Firefox’s SpiderMonkey JavaScript engine and means that complex JavaScript websites — which, let’s face it, is pretty much every website these days — should run faster. According to Mozilla, Firefox 9’s Type Inference should make the browser between 20 and 30 percent faster.
Alongside the faster JavaScript processing Firefox 9 continues to show improvements from Mozilla’s MemShrink project, an ongoing effort to reduce memory usage in the browser. Indeed, for the first time in a very long time my testing showed Firefox 9 using less memory than Opera (which has long been the least RAM hungry browser I test). Opening the same dozen tabs in both Firefox and Opera used only 367 MB of RAM in Firefox compared to 378 MB in Opera 11.60. There’s no longer much difference between the two, which is a testament to Firefox’s dramatic improvement over the last six months of MemShrink efforts.
Web developers get a few new toys in this release, including a fullscreen mode that allows any HTML element to take over the screen. Although fullscreen is primarily associated with video elements, there may be occasions (for example, HTML elements used in web-based games) where it makes sense to take over the screen. For now the fullscreen feature needs the -moz prefix to work.
Firefox 9 also includes a new “dim the lights” feature for HTML5 video. Dimming the lights means that Firefox will overlay the rest of the browser window with a gray background that let’s you focus on the video in question. Check out this demo video which shows the dimming in action.
While most of what’s new in Firefox 9 is under the hood, Mac users will notice a few cosmetic changes like a slightly tweaked look and feel that more closely matches the Mac OS X Lion toolbar styles. There’s also now support for two-finger swipe gestures to navigate back and forth in history (mirroring the same features in Chrome and Safari).
Firefox 9 is well worth the upgrade. If you moved away from Firefox due to speed problems and bloat this release warrants another look. Those plagued by the rapid release cycle’s habit of breaking add-ons may want to hold off though. Firefox 9, for all its other improvements, may still break some add-ons. Mozilla has a solution to the breaking add-ons problem in the works, but it won’t arrive for another six weeks when Firefox 10 is released.
Google Easter Egg Brings a White Christmas to Your Web Browser
Google offers up some frosty search results
If you’re still waiting for winter to arrive, Google can help. The search engine might not be able to bring you a white Christmas outside, but it can at least add some snow to your web browser. A recently uncovered Easter egg uses JavaScript to bury your search results under a fresh coat of snowy pixels.
To see the hidden feature just head to Google.com and search for the phrase “let it snow.” Provided your browser is up to the task — the latest versions of Chrome, IE, Safari and Firefox should all work — the search results page will begin to fill up with frost and snow.
Once the search results are sufficiently covered in white you can click and drag your mouse to write a message in the frost. And because nothing from Google is ever without a tie-in to Google+, just click the “+” button to share your Easter egg drawing with other Google+ users. To clear away the frost, click the “defrost” button.
Google is well known for its Easter eggs, the search results page recently did a flip for the phrase “do a barrel roll” and the company has even gone so far as to embed an entire flight simulator in Google Earth. If you’d like to see some other Google search Easter eggs, try typing “tilt“, “ascii art” (check out the Google logo) and our personal favorite, the quite subtle “recursion.”
Dabblet: An Interactive CSS ‘Playground’ in Your Browser
Dabblet: Live CSS editing (even better with monkeys)
CSS guru Lea Verou has unveiled a new project, Dabblet, which she describes as “an interactive CSS playground.”
Inspired by online editors like JSFiddle, Dabblet is an interactive testing app for CSS — write some code and instantly see the results in the same window. The site works in most modern web browsers, including Chrome, Firefox and Safari (Opera support is in the works).
Unlike JSFiddle where the emphasis is clearly on JavaScript, Verou’s app is designed from the ground up to focus on CSS. Among Dabblet’s nice features are automatic vendor prefixing for CSS 3 properties (via Verou’s -prefix-free library). The prefix-free script means you can just write, for example, border-radius instead of -moz-border-radius, -webkit-border-radius, -o-border-radius and so on.
Perhaps the most useful feature though is that Dabblet can save all of your work as GitHub gists. Not only those that making sharing your work with others easier it also ensure that even if Dabblet doesn’t last forever you’ll still have your data on GitHub.
The Dabblet source code is available on GitHub if you’d like to contribute or fork it for you own project (it’s licensed under the NPOSL 3.0 which carries a non-profit restriction).
Dabblet is simple to use, just dive in and start writing some code. However, not all of the advanced features are immediately obvious so if you’d like to see a kind of guide to Dabblet, head over to Verou’s blog where she has a basic screencast that shows Dabblet in action.
Microsoft’s New Automatic Update Plan Could Mean the End of IE 6
Microsoft has announced that starting in January 2012 Internet Explorer will, like Chrome, Firefox and Opera, no longer pester you with update notices. Instead Internet Explorer will automatically download and install updates in the background.
The new auto-update feature will only apply to users who’ve opted into the automatic updates through Windows Update. Those that have opted in will be upgraded to the latest version of IE available for their system. If you’re still on Windows XP that means you’ll be updated to IE 8. Vista and Windows 7 users will move to IE 9. The Windows Blog notes that when upgrading, your home page, search provider, and default browser settings will not be affected.
Internet Explorer updates have been offered through Windows Update previously, but unlike other “important” Windows updates, users needed to initiate the actual installation of IE updates via a dialog box. The only real change for most users in today’s announcement is that you’ll no longer need to mess with all those notification windows and dialogs. Instead IE will just seamlessly upgrade.
If you don’t want automatic updates, you can turn off Windows Update (though you should be aware that doing so could leave you with a insecure browser and operating system). Enterprise customers can opt out of the new auto-update mechanism using the IE 8 and IE 9 Automatic Update Blocker toolkits available from Microsoft.
The new auto-updating will ensure that users have the latest, most secure and stable version of IE, and web developers may be able to enjoy a fringe benefit as well — fewer IE 6 and IE 7 users on the web.
According to Microsoft IE 6 usage is currently at 8.4 percent worldwide, with some countries already under 1 percent while others, like China, remain high at 27.9 percent.
Microsoft has previously launched a campaign to kill off IE 6 and many large websites — like Google and WordPress — have already dropped support for the aging browser.
Web developers still supporting IE 6 may not need to do so much longer if Microsoft’s auto-update strategy pays off. Since the new auto-update mechanism will apply to IE 7 as well, it too may not need to be supported much longer. Of course, even in the best case scenario where IE 6 and 7 users drop below 5 percent worldwide, web developers would still need to contend with IE 8. While IE 8 was a huge step up from its predecessors, it still lacks support for most of the HTML5 and CSS 3 features found in modern web browsers.
Microsoft’s move to silent, automatic updates for Internet Explorer means that Apple’s Safari web browser is now the only browser that doesn’t default to automatically updating. Microsoft says that the auto-updating will roll out regionally, starting in January with users in Australia and Brazil and “scaling up over time.”
New WordPress 3.3: Less Flash, More Responsive Design
WordPress has released version 3.3. Dubbed “Sonny” after jazz saxophonist Sonny Stitt, WordPress 3.3 packs in a number of worthwhile upgrades, including a new responsive design that adapts the WordPress admin to smaller screens.
To get the latest version head over to the WordPress downloads page. If you’re already using WordPress you can update from the WordPress dashboard (naturally we suggest backing up your files and database before you upgrade).
Among the changes that make WordPress 3.3 well worth the upgrade is the new responsive admin design. While there are mobile apps from managing your WordPress site on the go, the actual web admin has never adapted to small screens. That changes with WordPress 3.3 and its new responsive admin page, which reflows content to fit the screen you’re using.
Responsive design — that is, using liquid layouts and scaling media to fit any screen size — is moving into the mainstream in a hurry. The past year has seen several high-profile websites relaunched with responsive designs, but WordPress 3.3 is likely the most widely used site yet to embrace responsive design.
Other changes in WordPress 3.3 include a slicker sidebar with “flyout” submenus which put everything in the admin site just a single click away. There’s also a new drag-and-drop uploader, which means you can drag and drop images from your desktop right into the media upload box in the admin (provided you’re using a browser that supports HTML5’s drag-and-drop API). Behind the scenes WordPress is using Plupload to handle the drag-and-drop features. In browsers that support it Plupload will use HTML5; for older browsers it falls back to Flash.
Anyone working on a site with numerous writers and editors will be happy to know that this release features much improved co-editing support. If you’ve ever seen messages like “Warning: [username] is currently editing this post,” you’ll be happy to know that it will now only appear when someone is actively editing a post. Previously the message would often appear even if your co-writer simply left the window or tab open in their browser.
For a complete list of changes and new features in WordPress 3.3, see the release notes.
Connect with ZionCG