CSS Trick Applies Fixed and Liquid Layouts to the Same Page
The debate over whether to use liquid or fixed layouts on the web is one of those perennial and not-very-interesting debates like Mac vs Windows or Emacs vs Vim. What if, however, there were a simple way to offer up both a fixed width and liquid layout on the same page? Peace on the web? Well, not exactly, but it’s a pretty clever trick nonetheless.
CSS guru Daniel Glazman (co-chairman of the CSS Working Group) shows you how to use just one pseudo class on a single HTML document and still create two different layouts, one liquid, one fixed.
In a fixed-width document named index.html, you usually have a rule setting the width or max-width of the main element. Something like
#main750 { max-width: 750px; }Right? Now think :target pseudo-class and tweak your style rule as followed:
#main750:target { max-width: 750px; }
Glazman’s trick relies on the :target pseudo-class to change the layout parameters when the URL includes #main750. In other words, the URL ending in just index.html would have a liquid layout while index.html#main750 would have a fixed layout.
It’s not necessarily ideal in this particular form, and it could be triggered accidentally if you have any “jump” links in your page, but :target is an often underappreciated pseudo class. Opera’s Håkon Wium Lie has another example using :target to change the background color of a page and another commenter on Glazman’s blog offers up this much more complex pure CSS image zooming example which uses (among other tricks) :target to pan around a zoomed image.
Latest Stats Say We’re Building a Fatter, Slower Web
Been feeding your site too many JavaScript donuts?
The web is getting fatter, as much as 25 percent fatter in the last year alone.
That’s right, based on the top 1,000 most visited sites on the web, the average page download size has jumped 25 percent since this time last year — 626 kB per page to 784 kB. That’s a hefty weight gain in just a year and of course usually the larger the page, the slower the page.
The latest page size data comes from the HTTP Archive, which keeps monthly tabs on the size of web pages.
As you might expect, the largest single type of content on the average page is still images, which account for 451kB of the total 784kB. Images alone do not, however, account for the rapid increase in page size.
Our friends over at Pingdom sliced and diced the HTTP Archive data and found that much of the remainder of the bloat can be blamed on JavaScript. CSS files are also getting bigger, but since they’re generally smaller to begin with, the increase doesn’t add nearly as much to the bottom line.
Here’s Pingdom’s take on the matter:
In terms of sheer size, images are still the biggest factor, but the fastest-growing content type by far is JavaScript. It is also the second-largest content type in terms of size.
CSS content has increased 25 percent in size, which may seem like a lot, but we are still talking about relatively small files. That increase doesn’t matter as much. It does matter, though, that every single content type is growing. Size optimization seems to have gone out the window pretty much across the board.
Pingdom goes on to note that if you expand the data sample beyond the top 1,000 most visited sites the trend is even more dramatic, with the average page size at nearly 1MB.
So the web is getting fatter on a diet of ever-richer JavaScript files and more sophisticated CSS, it’s worth asking — does it matter? After all, broadband is getting faster, 3G and even 4G are spreading in the mobile space and web browsers are speeding up their JavaScript engines with every release. Do we really need to worry about larger download sizes?
Bigger pages aren’t necessarily a problem until they outstrip the corresponding increases in bandwidth and performance gains in web browsers. Bigger pages are, after all, a natural outcome of more complex, more powerful sites and web applications. But assuming all of your users have fast connections can be a mistake, particularly with a global audience. Sure, users in South Korea might be able to download a 1MB page in the blink of an eye, but the same page is going to crawl over dialup in the rural United States.
What’s perhaps most alarming about the HTTP Archive data is the rate at which pages are growing. If the 25 percent jump were to continue, it would mean that in just five years the average size of a webpage would be nearly 2.5MB. And remember, that’s the average; many pages will be much, much larger. Relying on broadband speeds to keep pace with page size growth is risky at best.
At the same time throwing out modern app building tools like JavaScript is also a mistake. What’s disheartening about Pingdom’s analysis is that sites seem to be ignoring the middle ground and, according to Pingdom, “size optimization seems to have gone out the window.” The mystery is why very large, very popular websites would risk creating larger, potentially slower pages. That’s clearly a recipe for disgruntled users. New features are great, but if they slow down your site, no one is happy. It’s a well established fact that speed is the most important element of your website. Study after study show that users turn their backs on websites that take more than mere seconds to load.
There’s nothing you can do to help slim the top 1,000 sites (unless you happen to be in charge of one of them), but if you’d like to put your own website on a diet there are number of tools that can help you compress and compact your site. We suggest starting with Web Page Test to get a basic look at how your site loads and where you might be able to compress files. Another handy tool is Google’s Page Speed service, which can help speed up your site. Yahoo’s YSlow is another invaluable tool for diagnosing page load problems.
Other things worth experimenting with include using CSS 3 to replace background images (where possible), making sure that your scripts load through a CDN and optimizing your site for mobile networks.
[Donut image by D Sharon Pruitt/Flickr/CC]
Make Your Most Important Images Stay that Way With Responsive Images
Developer Dave Rupert helps you keep your cats properly scaled
If you’ve spent any time at all playing with responsive images (or adaptive images) you’ve probably noticed something about small screens — portrait-oriented images take on a much greater importance. The simple fact is that on the vertically-oriented small screen, taller images are larger and, thus, assume a greater importance.
As developer Dave Rupert puts it: Image Height == Image Importance.
The problem with that equation is that it often means that on mobile screens less important images suddenly steal the spotlight. Take an image with thumbnails below it for example. As Rupert recently found, when scaling down your designs, sometimes the image importance equation means the emphasis is wrong on small screens:
Our design employed a ~3:1 hero image with three ~4:3 thumbs below it. At full width it possessed the proper hierarchy: Biggest == Most Important. However, when resized and folded into a single column, the 3:1 image appears to be about half the height of the 4:3 images below it.
The solution for Rupert is what he calls, “Uncle Dave’s Squeeze n’ Crop Method,” which consists of a wrapper div and some very clever CSS combined with @media rules. Head on over to Rupert’s blog for the full solution and a little explanation of why it works. It’s not exactly cut-and-paste code you can just drop in your own projects since image dimensions and ratios will vary, but it’s definitely worth bookmarking should the problem arise in your own work.
Crashing Google Wave Finds New Life in Open Source
Google recently announced it will shut down Google Wave, the company’s web app for real-time collaboration, in April 2012.
Google had previously all but abandoned Wave, ceasing new development over a year ago, but soon all traces of Wave will be removed from the web. Wave will become read-only in January 2012, meaning users will no longer be able to create new waves. After that Google Wave users have until April 30 to export their content before the service shuts down completely.
The official demise of Google Wave is part of a larger spring-cleaning effort that will also see Google shut down services like Google Friend Connect, Google Gears and Google Knol, among others. Despite the heavy hype that accompanied its launch, Google Wave, like Knol and other soon-to-close services, just never caught on with average users. As the Google blog blithely puts it, these services “haven’t had the impact [the company] hoped for.”
While Google claims that cutting the cruft like Wave will help it refocus its efforts on more popular Google services, that’s not much consolation for fans of the doomed Wave.
Fortunately for Wave fans, the code behind Google’s service has been turned over to the Apache Software Foundation for safe open source keeping. There’s even a service, “Wave in a Box,” which replicates the basic Google Wave experience.
Wave in a Box consists of two parts, a standalone wave server and a web client. The Wave in a Box web client looks a bit different than Google’s Wave user interface, but the same features are present. The Wave in a Box tools also have the distinct advantage of decentralization. Developers can run wave servers and host waves on their own hardware without Google being involved in any way.
If you’d like to take Wave in a Box for a spin, head over to the demo site and sign up for an account. While the user interface is considerably more bare bones than the Google version, the demo site is nevertheless usable and surprisingly snappy.
If you like what you see, you can install Wave on your own server. Just grab the source code from the Apache site.
See Also:
The Trials and Tribulations of HTML Video in the Post-Flash Era
Adobe reversed course on its Flash strategy after a recent round of layoffs and restructuring, concluding that HTML5 is the future of rich Internet content on mobile devices. Adobe now says it doesn’t intend to develop new mobile ports of its Flash player browser plugin, though existing implementations will continue to be maintained.
Adobe’s withdrawal from the mobile browser space means that HTML5 is now the path forward for developers who want to reach everyone and deliver an experience that works across all screens. The strengths and limitations of existing standards will now have significant implications for content creators who want to deliver video content on the post-flash web.
Apple’s decision to block third-party browser plugins like Flash on its iOS devices played a major role in compelling web developers to build standards-based fallbacks for their existing Flash content. This trend will be strengthened when Microsoft launches Windows 8 with a version of Internet Explorer that doesn’t support plugins in the platform’s new standard Metro environment.
Flash still has a significant presence on the Internet, but it’s arguably a legacy technology that will decline in relevance as mobile experiences become increasingly important. The faster pace of development and shorter release cycles in the browser market will allow open standards to mature faster and gain critical mass more quickly than before. In an environment where standards-based technologies are competitive for providing rich experiences, proprietary vendor-specific plugins like Flash will be relegated to playing a niche role.
Our use of the phrase post-Flash isn’t intended to mean that Flash is dead or going to die soon. We simply mean that it’s no longer essential to experiencing the full web. The HTML5 fallback experiences on many Flash-heavy sites still don’t provide feature parity with the Flash versions, but the gap is arguably shrinking — and will continue to shrink even more rapidly in the future.
Strengths and weaknesses of HTML5 video
HTML5 has much to offer for video delivery, as the HTML5 video element seamlessly meshes with the rest of the page DOM and is easy to manipulate through JavaScript. This means that HTML5 video offers significantly better native integration with page content than it has ever been possible to achieve with Flash. The open and inclusive nature of the standards process will also make it possible for additional parties to contribute to expanding the feature set.
A single company no longer dictates what can be achieved with video, and your video content is no longer isolated to a rectangle embedded in a page. HTML5 breaks down the barriers between video content and the rest of the web, opening the door for more innovation in content presentation. Three are some really compelling demonstrations out there that showcase the use of video in conjunction with WebGL and other modern web standards. For example, the video shader demo from the 3 Dreams of Black interactive film gives you a taste of what’s possible.
Of course, transitioning video delivery in the browser from Flash to HTML5 will also pose some major challenges for content creators. The standards aren’t fully mature yet and there are still a number of features that aren’t supported or widely available across browsers.
For an illustration of how deep the problems run, you need only look at Mozilla’s Firefox Live promotional website, which touts the organization’s commitment to the open web and shows live streaming videos of Red Panda cubs from the Knoxville Zoo. The video is streamed with Flash instead of using standards-based open web technologies.
Flash is required to see the Red Panda cubs on Mozilla’s website
In an FAQ attached to the site, Mozilla says that it simply couldn’t find a high-volume live-streaming solution based on open codecs and open standards. If Mozilla can’t figure out how to stream its cuddly mascot with open standards, it means there is still work to do.
Two of the major technical issues faced by HTML5 video adopters are the lack of adequate support for adaptive streaming and the lack of consensus surrounding codecs. There is currently an impasse between backers of the popular H.264 codec and Google’s royalty-free VP8 codec. There’s no question that a royalty-free video format is ideal for the web, but the matter of whether VP8 is truly unencumbered by patents — and also meets the rest of the industry’s technical requirements — is still in dispute.
There is another major issue that hasn’t been addressed yet by open web standards that could prove even more challenging: content protection. The vast majority of Flash video content on the Internet doesn’t use any kind of DRM and is trivially easy to download. Flash does, however, provide DRM capabilities and there are major video sites that rely on that technology in order to protect the content they distribute.
Can DRM be made to play nice with open standards?
DRM is almost always bad for regular end users and its desirability is highly debatable, but browser vendors will have to support it in some capacity in order to make HTML5 video a success. Many of the content creators who license video material to companies like Netflix and Hulu contractually stipulate a certain degree of content protection.
Mozilla&’s Robert O’Callahan raised the issue of HTML5 video DRM in a recent blog entry shortly after Adobe’s announcement regarding mobile Flash. He expressed some concern that browser vendors will look for a solution that is expedient rather than inclusive, to the detriment of the open web.
“The problem is that some big content providers insist on onerous DRM that necessarily violates some of our open web principles (such as web content being equally usable on any platform, based on royalty-free standards, and those standards being implementable in free software),” O’Callahan wrote. “We will probably get into a situation where web video distributors will be desperate for an in-browser strong DRM solution ASAP, and most browser vendors (who don’t care all that much about those principles) will step up to give them whatever they want, leaving Mozilla in another difficult position. I wish I could see a reasonable solution, but right now I can’t. It seems even harder than the codec problem.”
O’Callahan also pointed out in his blog entry that the upcoming release of Windows 8, which will not support browser plugins in its Metro environment, means that the lack of DRM support in standards-based web video is no longer just a theoretical concern. Microsoft may need to furnish a solution soon, or risk frustrating users who want to watch commercial video content on the web in Windows 8 without installing additional apps or leaving the Metro shell.
Netflix stands behind DASH
Flash evangelists may feel that the limitations of HTML5 video and the problems that content creators are sure to face during the transition are a vindication of the proprietary plugin model. But the advantages of a truly open, vendor-neutral, and standards-based video solution that can span every screen really dwarf the challenges. That is why major stakeholders are going to be willing to gather around the table to try find a way to make it work.
Netflix already uses HTML5 to build the user interfaces of some of its embedded applications, including the one on the PS3. The company has soundly praised the strengths of a standards-based web technology stack and has found that there are many advantages. But the DRM issue and the lack of suitably robust support for adaptive streaming have prevented Netflix from dropping its Silverlight-based player in regular web browsers.
The company has committed to participating in the effort to make HTML5 a viable choice for all video streaming. Netflix believes that the new Dynamic Adaptive Streaming over HTTP (DASH) standard being devised by the Motion Picture Experts Group (MPEG) will address many of the existing challenges and pave the way for ubiquitous adoption of HTML5 for streaming Internet video.
DASH, which is expected to be ratified as an official standard soon, has critical buy-in from many key industry players besides Netflix, including Microsoft and Apple. An early DASH playback implementations is already available as a plugin for the popular VLC video application.
The DASH standard makes video streaming practical over HTTP and addresses the many technical requirements of high-volume streaming companies like Netflix, but it doesn’t directly address the issue of DRM by itself. DASH can be implemented in a manner that is conducive to supporting DRM, however.
DASH and DRM
Ericsson Research, which is involved in the DASH standardization effort, has done some worthwhile preliminary research to evaluate the viability of DRM on DASH. Ericsson produced a proof-of-concept implementation that uses DRM based on the Marlin rights management framework. Marlin, which was originally created by a coalition of consumer electronics vendors, is relatively open compared to alternate DRM technologies and makes use of many existing open standards. But Marlin is still fundamentally DRM and suffers from many of the same drawbacks, and adopters have to obtain a license from the Marlin Trust Management Organization, which holds the keys.
The architecture of the Marlin rights management framework
Ericsson explains in its research that it chose to experiment with Marlin for their proof-of-concept implementation because it’s available and mature — other similar DRM schemes could also easily be adopted. Existing mainstream DRM schemes would all likely pose the same challenges, however, and it’s unlikely that such solutions will be viewed as acceptable by Mozilla. More significantly, an implementation of HTML5 video that relies on this kind of DRM would undermine some of the key values and advantages of openness that are intrinsic to the open web.
The ease with which solutions like Marlin can be implemented on top of HTML5 will create pressure for mainstream browser vendors to adopt them quickly. This could result in the same kind of fragmentation that exists today surrounding codecs. As O’Callahan said, it’s easy to see this issue becoming far more contentious and challenging to overcome than the codec issue.
What next?
The transition to HTML5 and standards-based technology for video delivery will bring many advantages to the web. There are some great examples that show what can be achieved when developers really capitalize on the strengths of the whole open web stack. The inclusiveness of the standards process will also give a voice to additional contributors who want to expand the scope of what can be achieved with video on the web.
There are still some major obstacles that must be overcome in order for the profound potential of standards-based web video to be fully realized in the post-Flash era. Open standards still don’t deliver all of the functionality that content creators and distributors will require in order to drop their existing dependence on proprietary plugins. Supplying acceptable content protection mechanisms will prove to be a particularly bitter challenge.
Despite the barriers ahead, major video companies like Netflix recognize the significant advantages of HTML5 and are willing to collaborate with other stakeholders to make HTML5 video a success. The big question that remains unanswered is whether that goal can be achieved without compromising the critically important values of the open web.
See Also:
‘WTF Mobile Web’ Tracks Terrible Mobile Web Design
Sometimes the best way to figure out what works is to see what doesn’t. That’s the thinking behind WTF Mobile Web, a new site that tracks examples of terrible mobile web design and user experience. Whether it’s a “native look” that inevitably looks wrong on all but one platform or simply treating the iPad as a mobile browser, WTF Mobile has plenty of examples of what not to do when developing a mobile site.
WTF Mobile Web is the brainchild of developers Jen Simmons and Brad Frost who are careful to note that the point isn’t to be mean or pick on specific sites. In fact, perhaps the best part about the site is that, as people were quick to point out, it’s guilty of some of the very same things it’s calling out in other sites. Hypocrisy? Sure, but it also illustrates just how hard it is to get mobile right.
As Simmons and Frost write:
The problem is that we’ve all been doing this thing called Making a Website for a long time in a particular way. And now everything is changing. Sure some developers are resistant to learning new things, but most developers are interested, excited and willing. But this isn’t a problem that you can fix by just switching out which bit of code to use. It’s bigger than that. Content strategy, design, business all have to change. The fundamental way in which people work together to plan and coordinate the creation of a website has to change.
Perhaps the most important thing to keep in mind is that, to paraphrase developer Steven Hay, there is no mobile web, no desktop web, no tablet web. There is just The Web, which we view in different ways. Design for The Web, avoid assumptions about devices (like assuming the iPad is a mobile device) and please, stop with the “native” designs.
If you run across an example of bad mobile design you can submit it to WTF Mobile Web.
So how do you build better mobile sites? Well, WTF Mobile Web has a few links to get you started, including one to Frost’s Building a Future Friendly Web slideshow, which we’ve covered before. Webmonkey has also been covering mobile and responsive design for some time so be sure to read through our archives.
WTF? photo by Daniel Lobo/Flickr/CC
See Also:
Damn the Torpedos: Mozilla Adds Flash to Firefox for Android
Flash Player running in Firefox for Mobile. Photo: Scott Gilbertson/Wired.com
Adobe may be abandoning Mobile Flash, but Mozilla is pushing forward with Flash in Firefox for Mobile. In addition to the new native Android UI we recently showcased, the latest nightly builds of Firefox for Android now offer experimental support for the Flash plugin.
If you’d like to give it a try, head over to the Mozilla nightly builds page and download a copy of Firefox for Android (note that if you have the beta release installed you’ll need to remove that first). Once the download is finished just open the file to complete the installation and setup.
The nightly builds are, obviously, not stable releases, but I took the latest version for a spin on a Dell Venue and had no problems watching Flash movies. Or I should say no technical problems with Firefox for Android. The browser didn’t crash and Flash worked as advertised in that it loaded and attempted to play movies. Sadly playback was jittery at best, often fell out of sync with the audio and more or less made a good argument for why Flash doesn’t work well on under-powered mobile devices (all testing was done over wifi).
Flash’s lackluster performance isn’t Firefox’s fault, but that probably won’t stop users from blaming the browser. In truth how well Flash performs in Firefox for Android will vary considerably based on your phone’s hardware.
While Flash on mobile is imperfect enough that even Adobe is done with it, Mozilla reports that 21 percent of Firefox for Android’s 1 and 2 star reviews come from users requesting support for Flash. For those that have been waiting for Flash, rest assured, Firefox for Mobile is indeed getting Flash support, though the final version won’t arrive until Firefox 10 ships early in 2012.
See Also:
Archive Your Social-Network Life With ThinkUp 1.0
A few of the things ThinkUp can do for your social-network life
ThinkUp, the web-based data-liberation and analytics application from former Lifehacker editor Gina Trapani, has just released version 1.0.
Social networking is often very ephemeral: You post something, a few people respond, and then the conversation just evaporates, disappearing into the ether. One of ThinkUp’s goals is the give your social-network posts a longer life and ensure that you’ll have a way to refer back to those conversations years later.
ThinkUp is a web-based app that pulls your data out of social silos like Facebook or Twitter and stores it on your own server. You control your own data, and have a record of your conversations potentially long after Facebook, Twitter and the rest have become mere footnotes in the history of the web.
“The conversations you have online are worth capturing, keeping, and referring back to over time,” writes Trapani on her Smarterware blog. “In fact, the things you share and the conversations you have about them gain weight, perspective, and importance over time, not just the moment you post them.”
The backup and archiving features alone would make ThinkUp a worthwhile app to have, but the real analytical power of ThinkUp comes after it has a local copy of your data. That’s when ThinkUp starts slicing, dicing and pulling together your data to reveal things about your online activity that you’ve never considered before.
For example ThinkUp can pull conversations together, plot them on a map, reveal which of your posts are the most popular, which are the most replied to and even track all the links your friends have ever sent you.
We took a detailed look at the software back when the beta was first released. Now ThinkUp is out of beta and ready for prime time with a 1.0 release.
The first step to using ThinkUp is installing the app on your server. The requirements are modest and installation is automated — if you can install WordPress, you can install ThinkUp. Of course not everyone is comfortable installing WordPress so ThinkUp takes a page from Dave Winer and offers a ThinkUp instance running on Amazon EC2. Just follow the link, sign in to your Amazon account and you’ll have ThinkUp running in no time (the first year is free for new EC2 users, $ 15/ year for the rest).
Once ThinkUp is installed you need to point it to your accounts. I tested it with Twitter and Google+ and had no problems importing data. One nice touch that’s been added since the beta release is a secret RSS feed for running the ThinkUp updater. Sure, you can add a cron job if you know what you’re doing, but for novice users the RSS feed is an ingenious tool — just add it to your favorite RSS reader (for example, Google Reader) and the reader will periodically scrape the feed, triggering the update.
The Twitter Dashboard in ThinkUp
Because ThinkUp pulls in your raw data it can show you useful stuff you won’t find on the social networks themselves. This is particularly noticeable with Twitter, which really shows very little beyond the most recent few tweets from your friends. ThinkUp takes the same data Twitter has and actually puts it to good use, showing, for example, your most replied-to posts, your most re-tweeted posts and, my personal favorite, conversations you have with other Twitter users. It also tracks everything your followers do as well. For example, ThinkUp catalogs all the links your followers have posted, displaying them all in one place. There’s also an excellent search function for tracking down old tweets.
While ThinkUp puts a tremendous amount of data at your fingertips, it manages to keep the interface simple enough that the data is never overwhelming.
ThinkUp also now makes it possible to host your conversations at a permalink on your site. It’s a feature that’s particularly useful if you frequently ask your Twitter followers for advice or suggestions. For example, here’s a page where Trapani asks her followers which iPad apps they recommend.
ThinkUp is already in use on several popular Twitter accounts, like, for example The White House (Steve Martin is also a fan) and in my testing it worked without a hitch. If you’re comfortable setting up basic software like WordPress, installing ThinkUp should be a snap and if you’re not confident around a server there’s always the Amazon-based version.
If you’d like to see more of what ThinkUp has to offer, check out the video below:
See Also:
Get More Out of Your Browser’s Developer Tools
Inspecting Webmonkey in Chrome
Every web browser now ships with some sort of developer tools built-in. The only exception is Firefox, but that’s changing soon (and of course Firefox is also home to the add-on that started it all — Firebug). In fact web developers have come to rely on these tools so much that it’s difficult to remember what we did before Firebug, WebKit Inspector, Dragonfly and the rest of the browser tools (we swore a lot more, among other things).
Whether you need to manipulate DOM elements, inspect CSS styles, edit HTML elements or step through JavaScript the browser developer tools make it easy to do. And no matter how much the browsers’ various developer tools are a part of your daily workflow there’s always some new tricks to learn.
If you’d like to dive a bit deeper into the world of browser developer tools and learn quite a few handy tricks you might not be aware of, head over to developer Andi Smith’s blog and read through his recent post 25 Secrets of the Browser Developer Tools. Smith gives an in-depth walk-through of some lesser known features and even points out which tools support them, which don’t and variations between them.
Of course thanks to differences between browsers and tools not every tip works the same way (or at all) in every browser, but if you’re a web developer you’ve most likely got a copy of every browser installed anyway and jumping back and forth between several is probably second nature.
Among Smith’s twenty-five suggestions are tips like how to perform calculations right in the browser, how to expand minified JavaScript, how to save your CSS edits, store revisions and perhaps the most helpful — how to quickly disable the browser’s cache. For more tips head over to Smith’s post, and be sure to check out the comments where readers chime in with their own lesser known tips.
Our own tip to add to the list is limited to Chrome/Chromium and is very simple, but often overlooked — don’t forget about you can drag-and-drop. The Elements tab in Chrome’s inspector panel allows you reorder the source of the page by dragging and dropping HTML elements. Dead simple, but sometimes handy for debugging misbehaving floats and other CSS mysteries.
See Also:
Mozilla Hatches Plan to Tackle Memory Leaks in Firefox Add-ons
Mozilla began an aggressive campaign earlier this year to trim Firefox’s memory footprint with a new initiative called MemShrink. The first fruits of that effort landed in Firefox 7, which was released in September. As a result, Firefox’s memory consumption is now between 20 to 50 percent lower. Building on that success, Mozilla is expanding the scope of its MemShrink initiative and looking to address memory consumption in additional areas.
In a blog post published earlier this week, Mozilla’s Justin Lebar proposed a strategy for tackling memory leaks in third-party add-ons — a common source of Firefox memory problems. Firefox’s add-on ecosystem is one of the browser’s great strengths, but it also presents challenges.
Add-ons can behave in unpredictable ways — it’s not always clear to users when a problem they encounter in Firefox is caused by the browser or by third-party code. As Lebar says, the time has come for Mozilla to start taking a more active role in protecting users from add-on misbehavior. Mozilla already loosely polices its add-on site to protect users from malware, so taking proactive steps to flag leaky add-ons seems like a logical step.
“The fact is, if we take credit for our vibrant add-on community, we must take responsibility for the problems those add-ons cause,” Lebar wrote. “This shouldn’t be controversial; we already check to ensure that add-ons aren’t outright malicious before posting them to AMO, acknowledging that the buck stops at Mozilla when there’s a misbehaving add-on. Even if it’s not our bug, it’s in our software, and people will blame us, not their add-ons.”
Lebar’s proposed strategy includes three approaches, which he calls the carrot, the stick, and the wrench. The carrot approach will involve changing Mozilla’s add-on website so that testing for “zombie compartments” that leak memory is a standard part of the process for submitting a new add-on.
The stick approach will involve flagging and publicly identifying add-ons that leak a lot of memory-much like a previous experiment in which slow add-ons were named and shamed. Finally, the wrench approach will involve building better tools that will make it easier for add-on developers to identify and resolve memory leaks themselves.
Lebar suggests using all three approaches together. Tickets have been opened in Mozilla’s bug tracker to facilitate developer discussion about the proposal and how to proceed with an implementation. Users can hopefully expect to see a meaningful improvement in add-on memory overhead when the plan goes into effect.
This article originally appeared on Ars Technica, Wired’s sister site for in-depth technology news.
See Also:
Connect with ZionCG