It’s Independence Day, so what better topic to discuss than the juridical matters of the United States? (Frankly, there are more substantive topics to address, to be sure — as a palliative I direct your attention [yet again!] to the Federalist Papers for one such topic — but a dash of humor with underlying substance is never out of order.) Here follows a brief anecdote I ran across recently:

In Gilchrist v. O’Keefe, 260 F.3d 87 (2001), Sotomayor wrote for the panel, which rejected an inmate’s claim that he was unconstitutionally deprived of his right to counsel during his state sentencing proceeding when the trial judge declined to appoint a new attorney to replace the attorney who withdrew after the inmate punched him in the head.

See the original source, as well as the decision itself.

It is worth highlighting that the fact that the deprivation occurred during “state sentencing” is critical to the opinion, as 28 U.S.C. § 2254(d)(1) (the relevant clause in US code) prevents granting relief in response to a state proceeding, assuming the decision was not “contrary to clearly established Federal law” (which, the decision notes, it was not). As a consequence the decision need not (and does not) reach any question along the most obvious line suggested by the quote, at least not outside of dicta (with which, tangentially, I am not particularly inclined to disagree) — an example of how legal decisions need not be as obvious as they seem, and an example of how common sense may play little to no part in the legal reasoning of a “common-sense ruling”.

Based on newsgroup postings, users did not get the news that Firebug 1.4 requires a manual reload the first time you open it on a site. Ok, no I don’t know how they would know. So here it is:

In 1.4, when you open Firebug on a page it does not automatically reload the page. You have to do it manually.

In 1.3, the page was reloaded for you. We made this change because some users (ok it was Steve , complained that the reload was not always necessary and sometimes wastes time. This is especially true for users who are primarily interested in HTML and CSS or for users who want to know just when the reload is triggered so they can watch how the page loads.

But why do we need to reload at all? Well to track net traffic, to track script loading, and to listen for console logging we have to add listeners on the page before the page load begins.   If Firebug is not active at the time of page load, none of this happens. So after you open Firebug you have to reload to get all the info. That was true in 1.3 and it still true in 1.4. The only change here is that 1.4 you have to do it manually.

By now my brain automatically hits reload when I open Firebug, since I always want all the info on all the panels

jjb

Please post follows to the newsgroup.

I have been accepted to present a short paper entitled “Ubiquity: Designing a Multilingual Natural Language Interface” at the ACM SIGIR Workshop on Information Access in a Multilingual World in Boston on July 23rd. I’ll probably be there in Boston a few days before or after as well in order to find an apartment for the fall. If anyone is in Boston at that time and would like to meet up, or if you’re near Cambridge and looking for an apartment-mate, please let me know.

If you would like to see a preprint of the paper, please contact me at x@x.com where x=mitcho.

Related Posts

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

In March, I posted about using article feedback to improve knowledge base articles and the importance of making knowledge base articles easy to read; but those are specific areas that are part of a greater knowledge base goal, which is to make the process of Firefox self-help as easy as possible.

There are few sources of information to we draw from:

• Top searches: The most common search terms in the SUMO Weekly metrics document.
• Weekly common issues: Our Weekly Common Issues page tracks the most common support issues each week.
• Article polls: At the bottom of each article, there are poll questions: “Did this article solve a problem you had with Firefox?“, “Was this article easy to understand?“, and “Please rate your experience with solving your problem on support.mozilla.com from 1 to 5” (For more precise data there’s the PageView Data.)
• And of course, Article comments: There is a text field on each article for users to provide feedback about the article. When logged in as a contributor, that feedback is displayed at the bottom of the article.

Here’s how that data is utilized to measure the quality of the knowledge base, and make it better:

The top search terms are tested to find out if the first search results contain the article the user is most likely searching for.
If they don’t:

• The correct article may need to be renamed to match the search term.
• The top article in search results may be mistaken for a different issue; so a link to the correct article is added in the intro of the first search result. If users are being redirected to the correct article, the poll data should improve.
• Keywords that match the search terms are added to the correct article.

For generic search terms the article comments for each result may clarify what users are asking about.

The weekly common issues page is checked for any items that need documentation in the knowledge base. If enough information is available to create documentation, the relevant articles are updated or a new article is created.

The comments in articles with the lowest understandability score are checked to get details on what is not understandable in the article, so we can assess what can be done to eliminate that confusion. Sometimes that means rewording or reformatting the article. In some cases it is a matter of adding screenshots. In other cases, it’s a matter of streamlining or purging the article to simplify it for users.

In the end, it’s about taking the data, analyzing why the data is what it is, and what we can do to improve each issue. As a result, the article poll scores should go up, and users will get answers to their questions about using Firefox. We’ve outlined these tests in a contributor page, so everyone as a community can be most affective in making the knowledge base better each week. You can post any suggestions for improvement in the Contributors forum.

Funny: Ad blocking software like AdBlock Plus may cause animation to not play. Please disable.

You want to use @font-face, then you realize it’s got some downsides. First of all, it’s another HTTP request, and we know that the golden rule of web performance is to keep HTTP requests to a minimum. Secondly fonts aren’t even small files, they can be 50k+ in size. Lastly the lag of fonts loading last means you page seems to morph into it’s final form.

Here’s a cool little optimization. By using a data: URL you can use the font inline by encoding in base64. For example:

    @font-face {
      font-family: "My Font";
      src: URL("data:font/opentype;base64,[base-encoded font here]");
    }

    body { font-family: "My Font", serif }

You can see this in action here. This seems to work fine in Firefox 3.5, and Safari 4 (presumably any modern WebKit based browser). Other browsers will simply act as if they don’t support @font-face.

In practice I’d recommend putting it in a separate stylesheet rather than inline CSS so that your pages are smaller and CSS can be cached for subsequent pageviews.

Data URL’s are part of Acid2, which most modern browsers either pass or plan to pass. If you use an Open Type font you’d get pretty decent compatibility (IE only supports Open Type). Using True Type you’d still get pretty good compatibility sans IE. Check the @font-face page on MDC for more details. Unlike images, browsers that support @font-face are likely to support data: URL’s as well, making this a pretty good solution.

Special thanks to Open Font Library for having some nice free fonts with awesome licensing. This post was partially in response to a comment left the other day on my @font-face hacks blog post.

This Week

Governance

• Careful comments on fligtar's proposal for changing the AMO sandbox model
• Started looking at the issue of whether we have private mailing lists which shouldn't be private
• Worked with harvey on streamlining procedure for e-signing Committer's Agreements
• Mitchell resolved weekly update meeting move discussion; will now be 11am Monday

Bugzilla

• Summarised where we are so far
• Call with justdave about b.m.o. update procedure, technical feasibility of various plans

Other

• Watched Firefox 3.5 release process with admiration
• Updated Firefox Language coverage data for 3.5 and reblogged it
• Finished OpenTech presentation (nearly)
• Mentored SoC students:
  • Pedro has written a plan which looks very good, and will start implementation this weekend
  • Am working with Seulki to redefine the scope, as the original idea is looking difficult

Next Week

• OpenTech 2009 presentation on the Open Internet (Saturday)
• Firefox Launch Party, London (Monday)
• Make sure sweepstake winners get their prizes
• Wednesday off to prepare summer Bible studies
• Try and unblock some issues now people are not swamped with Firefox 3.5

• The nightlies in latest-comm-1.9.1 are the official ones now.
• FTP has latest-comm-central and latest-trunk symlinked to latest-comm-1.9.1 for the first part of the transition.
• Those are static builds with reduced build size and hopefully better performance.
• Dependent builds ("build" columns, "hourlies") continue to be shared builds.
• Linux has a "leak test build" column that runs debug builds.
• Nightlies and dependent builds are being run on x86_64 Linux, even though this should still not be considered a tier-1 platform and has no L10n builds.
• Localized nightlies are in latest-comm-1.9.1-l10n and built with the "L10n merge" tooling that injects en-US for missing strings, eliminating most cases of the "yellow screen of death".
• The SeaMonkey tinderbox waterfall page has those buildbots reporting as columns containing "comm-1.9.1" in their names.
• Due to ongoing slight instabilities in the 10.5 VMs, the old "comm-central" 10.4 unit test machine stays up there as well.
• All other comm-central builds disappear from the scene.
• For localizers, the comm-1.9.1 builds on their Mozilla-l10n-* waterfall pages are the relevant reference.
• All VMs on the same platform run in generic pools, so that any of the machines can do any dependent build, nightly, L10n repackaging or unit test run, the buildbot master hands those jobs on a "first come, first serve" basis to the available slaves.

• Builds with mozilla-central are set up in addition, uploading nightlies to a latest-comm-central-trunk directory.
• A version number of "2.1a1pre" is used there for now, there's no definitive decision on what version the next SeaMonkey will be yet though, this is the lowest possible version to use atm.
• FTP symlinks for latest-comm-central and latest-trunk are removed.
• The comm-1.9.1 builds are switched to report to a new SeaMonkey2.0 tinderbox waterfall page (as well as the 10.4 tests).
• The comm-central-trunk builds report to the SeaMonkey page.
• No unit test builds will be activated for comm-central-trunk while we don't have all the machines we need in the pools (due to Parallels network problems).
• L10n builds for comm-central-trunk use l10n-central work and also report to the Mozilla-l10n-* tinderbox waterfalls, dashboard for this might only come up some time later.

• Unit tests for comm-central-trunk are turned on.
• A few other incremental improvements can be thought of when Phase II is completed, such as running packaged tests, AUS for L10n, etc. but all those can be done individually, step by step, then.
• Once 10.5 Mac VMs are completely stable and not intermittently crashing because of Parallels issues, we'll turn off the 10.4 unit test machine and hand it back to Mozilla IT.

Maciej Stachowiak, Apple: “I’m surprised at the level of confidence expressed in Theora not infringing unknown patents…”

That’s right folks, it’s working group amateur hour. Step right up, try your hand.

Accessibility is a pretty hairy issue in web development. When attempting to determine if your site is accessible, there are so many standards and recommendations to follow. 508, WCAG, WCAG 2.0, WAI Priority 1, 2 & 3.

Well, now there is a new standard from the W3C called WAI-ARIA (Web Accessibility Initiative - Accessible Rich Internet Applications)

The simplest definition of ARIA is adding UI semantics via HTML element attributes. Simply, you add things like ‘<div role="nav">‘ or ‘<form role="search">‘ to specific HTML elements to give screen readers a better understanding of your content.

The ARIA spec is huge (160 pages), so I won’t go over every part of it in detail. The four areas I will focus on are landmarks, required, invalid and live regions.

ARIA Landmarks

Today, when a blind user encounters a website, navigation between elements of the page can be difficult because there is no established method of marking areas of the page as navigation, content, footer, etc. Luckily with ARIA, we can.

Here’s some example markup of a typical webpage:

<div id="header">
    <h1>My Awesome Website</h1>
    <form> </form>
</div>
<div id="content">
    <ul id="nav"></ul>
    My website rocks!
</div>
<div id="footer"></div>

And here’s what it looks like with ARIA Landmarks:

<div id="header" role="banner">
    <h1>My Awesome Website</h1>
    <form role="search"> </form>
</div>
<div id="content" role="main">
    <ul id="nav" role="navigation"></ul>
    My website rocks!
</div>
<div id="footer"></div>

What I’ve done is add ARIA roles to certain parts of the page (header, nav, search form, primary content). Because the roles are a defined spec, screen readers can parse the page for roles and allow a user to jump to each part without having to navigate through all the content.

ARIA Required & Invalid

Another part of the ARIA spec is the attribute ‘aria-required’ and ‘aria-invalid’. These attributes are for communicating to screen readers that a particular form field is required and/or invalid without requiring the user to look for asterisks or other text near the field. The screen reader would alert the user to this information. Here’s an example:

<form id="searchform" role="search">
      <p class="error">You did not enter a search term</p>
      <input name="query" value="" aria-required="true" aria-invalid="true" />
</form>
 

The above code has the ‘aria-required’ and ‘aria-invalid’ attributes set to true. When a screen reader encounters this code, it will read aloud ‘required’ and ‘invalid’. This is a lot simpler for a user than attempting to find error messages and/or asterisks in the page.

ARIA Live

A particularly difficult area of accessibility is dealing with AJAX. How can you communicate to a screen reader that content is loading or has changed? Thankfully, with ARAI Live Regions, it is quite simple. Here’s an example:

    <div id="sidecontent" aria-live="polite"> AJAX content goes here... <div>

Adding the ‘aria-live’ attribute to an element alerts a screen reader that content will change in this region and to read it aloud when it does. The aria-live attribute has ‘politeness’ levels, which allow you to specify how polite the updates should be. The four levels are

• off - updates are not communicated
• polite - notify of changes only when the user is not doing anything
• assertive - announce as soon as possible, but not interrupting the user
• rude - which will be read aloud immediately

The various levels of politeness allow for different situations where users would need to be notified immediately of important information or for content that is not as important.

Summary

This is just a quick overview of ARIA and its uses, but I’m really excited about the possibilities it creates. We can communicate the intent of our content much more explicitly. There’s also a lot of other aspects to ARIA including widgets (slider, checkbox), application structure (alerts, log, progressbar) and document structure (article, grid, definition) that are exciting.

Further Reading

• Longer ARIA overview
• ARIA Spec
• Setting up a screen reader
• Accessible widgets with ARIA

It has been a while since we announced the Koala - Komodo Advanced Localization Assistant - Project. While we work on the project on a nearly daily basis, we are just three students that need to do other work (like preparing for the upcoming examinations...), and because of that, the progress isn't as fast as it could be, if Koala would be our only project, but: we have a target for the final release: August, 23rd - September, 15th - and we plan not to miss it.

Our project schedule is of course more detailed - it consists of four big stages: preparation, implementation, integration and stabilization. That's the process of software development we did learn at our university, and our goal is to develop Koala that way.

During the first project stage, preparation, we've investigated as much as possible how Koala should work and look like, and as a result, we have written the Software Requirements Specification and Software Architecture documents.

In the Software Requirements Specification, we've listed the must-have features and have split them into modules with similar or dependent functionalities. In the now ongoing implementation stage, we are working on that modules separately. What does this mean? We code e.g. the "compare-locales" access module, make a few tests to be able to test it if it works as expected - and leave it there. So it's a single module, not (yet) connected with other modules.
As a result of this software development model, it's not possible to have something you "could touch" now - there won't be anything really usable until the next phase of development.

During the integration stage, we will make an working extension out of the many standalone modules. We will connect the modules through the, in the preparation stage specified, API's, one by one. It may look easier than it'll be, because this stage never comes as expected.
That will be also the time where we will start releasing pre-release versions of Koala: alpha and beta releases. They are to be expected late July.

After getting rid of the biggest blockers, we will enter the stabilization phase, where we will just fix known bugs and look for yet undiscovered bugs, by: testing, testing and testing. Because of that, in the middle of August you can expect an release candidate (hopefully just one).

The final release target is August, 23rd with a margin up to September, 15th.

If you'd like to help us in any way with this project, please drop a line in the comments.

Short update: between writing this posting and publishing it, we already entered the integration stage - but because of our examination session, the integration will start at full speed not earlier than in about three weeks.

More than 7 years ago, I wrote that XHTML2 was a major strategic mistake that had to be stopped immediately. In fact, I started saying so even earlier than that. Today, XHTML2 is no more. It takes with it into the grave CURIE, HLink and XFrames. Specs that nobody ever seriously considered as part of the future of the web, nobody outside of the XHTML2 WG of course.

Anyway. It's a good move but a move that comes too late. That decision should have been taken YEARS AGO. What a waste of time, money and energy. What a bad sign to the community. Many people thought the following : "it's good these specs are in the xhtml2 wg, we don't want them elsewhere".

R.I.P.

We will have a scheduled maintenance window tonight from 7:00pm to 11:00pm PDT. The following changes will take place:

• 7:00pm PDT (0200 UTC) graphs.mozilla.org update. We’ll be updating graphs.mozilla.org to pick up code updates (bugs 501432 and 498802). Duration 4 hours.
• 8:00pm PDT (0300 UTC) DHCP infrastructure changes. We’ll be implementing an active/standby DHCP server setup which requires some reconfiguration on the current DHCP server. No downtime expected.
• 10:00pm PDT (0500) UTC hg repo maintenance. We’ll be resetting the hg repo (bug 500246). Duration 30 minutes.

Please let me know if you have any reason why we should not proceed with this planned maintenance. As always, we aim to keep downtime to as little as possible, but unexpected complications can arise causing longer downtime periods than expected. All systems should be operational by the end of the maintenance window.

Feel free to comment directly in those bugs if you see issues past the planned downtime.

We launched ActiveState Code today, and there was much rejoicing. Yaaaah!

ActiveState Code is a site for sharing code recipes. It is the replacement for the popular ASPN Cookbooks (especially the Python Cookbook, which was a collaboration with O’Reilly and Associates that resulted in two print cookbooks using recipes from the site). The new site adds things like tagging, the ability to add recipes in a number of other languages, and a fresher and hopefully more usable site.

Migration should be easy. All recipes from the Python, Tcl and PHP Cookbooks have been carried over. Redirects maintain all old aspn.activestate.com/ASPN/Cookbooks links. Recipe id and author ids have been maintained. The ASPN Cookbook categories have been translated into tags in the new system — full details here.

I welcome any feedback on the site.

Cross-posted from hacks.mozilla.org

We’ve just launched Firefox 3.5, and we’re incredibly proud. Naturally, we have engaged in plentiful Mozilla advocacy — this site is, amongst other things, a vehicle for showcasing the latest browser’s new capabilities. We like to think about this release as an upgrade for the whole World Wide Web, because of the new developer-facing features that have just been introduced into the web platform. When talking about some of the next generation standards, the appearance of the number “5″ is almost uncanny — consider HTML5 and ECMAScript 5 (PDF). The recent (and very welcome) hype around HTML5 in the press is what motivates this article. Let’s take a step back, and consider some of Mozilla’s web advocacy in the context of events leading up to the release of Firefox 3.5.

Standardization of many of these features often came after much spirited discussion, and we’re pleased to see the prominent placement of HTML5 as a key strategic initiative by major web development companies. Indeed, exciting new web applications hold a great deal of promise, and really showcase what the future of the web platform holds in store for aspiring developers. Many herald the triumphant arrival of the browser as the computer, an old theme that gets bolstered with the arrival of attractive HTML5 platform features that are implemented across Safari, Chrome, Opera, and of course, Firefox (with IE8 getting an honorable mention for having both some HTML5 features and some ECMAScript, 5th Edition features).

Call it what you will — Web 5.0, Open Web 5th Generation (wince!), or, (R)evolution # 5, the future is now. But lest anyone forget, HTML5 is not a completed standard yet, as the W3C was quick to point out. The editor doesn’t anticipate completion till 2010. The path taken from the start of what is now called HTML5 to the present-day era of (very welcome) hype has been a long one, and Mozilla has been part of the journey from the very beginning.

For one thing, we were there to point out, in no uncertain terms, that the W3C had perhaps lost its way. Exactly 5 summers ago (again, with that magic number!), it became evident that the W3C was no longer able to serve as sole custodian of the standards governing the open web of browser-based applications, so Mozilla, along with Opera, started the WHATWG. Of course, back then, we didn’t call it HTML5, and while Firefox itself made a splash in 2004, the steps taken towards standardization were definitive but tentative. Soon, other browser vendors joined us, and by the time the reconciliation with W3C occurred two years later, the innovations introduced into the web platform via the movement initiated by Mozilla had gained substantial momentum.

The net result is a specification that is not yet complete called “HTML5″ which is implemented piecemeal by most modern browsers. The features we choose to implement as an industry are in response to developers, and our modus operandi is (for the most part) in the open. Mozilla funds the HTML5 Validator, producing the first real HTML5 parser, which now drives W3C’s markup validation for HTML5. That parser has made its way back into Firefox. It’s important to note that capabilities that are of greatest interest (many of which are showcased on this blog) are not only developed within the HTML5 specification, but also as part of the W3C Geolocation WG, the Web Apps WG, and the CSS WG.

The release of Firefox 3.5, along with updates to other modern browsers, seems to declare that HTML5 has arrived. But with the foresight that comes with having been around this for a while, we also know that we have a lot of work ahead of us. For one thing, we’ve got to finish HTML5, or at least publish a subset of it that we all agree is ready for implementation, soon. We’ve also got to ensure that accessibility serves as an important design principle in the emerging web platform, and resolve sticky differences here. Also, an open standard does not an open platform make, as debates about web fonts and audio/video codecs show. We’ve got a lot of work ahead of us, but for now, 5 years after the summer we started the ball rolling, we’re enjoying the hype around (R)evolution Number 5.

Our Drupal installation has been upgraded to version 5.19 to address a security vulnerability. Let us know if you encounter any problems.

How to grow communities is a hot topic these days. Francesco Lodolo recently blogged about how the Mozilla Italia community mainly consists of veterans who have been participants for several years, and how hard it is for them to find new contributors.

Illustration: Grow by Amy.Ng

Abdulkadir Topal from the German community also blogged about getting help for localization work on the European Mozilla Community Blog and reached an interesting conclusion about how to turn new and casual contributors into long-time community members: the key is to distribute ownership.

Kadir uses Thomas from the German localization team as a good example of this theory: Thomas is a relatively new community member (”only” two years worth of contributions so far!), yet he is one of the most active members on SUMO today. The key factor for why this happened, according to Kadir, is that Thomas was given full responsibility for the SUMO component within the German localization team.

As Kadir concludes, it’s “one thing to contribute little bits and pieces to a [project], but it’s a completely different thing to own it.”

I find this theory interesting. Maybe it is not a universal law that can be applied to everyone or every type of project/responsibility, but looking back at my initial involvement with Mozilla, ownership was definitely part of what motivated me — but not all of it, as I will explain below.

Kadir mentions in his blog post that it was something as trivial as a product logo that made me discover the Mozilla project in the first place. To me, the little Gecko logo — featured in an article about the planned Netscape 6 browser based on the previously open-sourced Netscape 4.x codebase — communicated “lean and mean,” and the article went on explaining how this new Gecko HTML rendering engine would be modern, compatible, portable, and small enough to be used even in future handsets (and guess what; about nine years later it turns out that they were right!).

Just a few days later, I learned that Netscape 6.x was just a branded and slightly outdated version of something called “Mozilla,” which apparently was the open source project behind the well known Netscape browser. I immediately switched to Mozilla instead, since it was more bleeding edge and therefore more fun for a geek like me.

That’s how it started for me. However, that wasn’t the reason why I sticked. Why did I turn from just interested in Mozilla to a deeply involved contributor? I will try to explain this and get back to Kadir’s theory, but I can say right now that there is a lot more than one reason why I’m still an active Mozilla community member.

It started around year 2000 with the realization that I could actually affect the project by submitting bug reports and providing feedback. Although open source as a concept wasn’t new to me, I had never actually gotten involved myself before. This, combined with the fact that I got to know other people with similar interests, made reading the newsgroup daily a pleasure.

However, I always felt that the original Mozilla suite represented something from the past, and that the way of the future was something lean and mean (yes, that Gecko logo that got originally got my attention!). The word “monolithic” was often used to describe the Mozilla suite, and even the word itself felt big, old and unmanageable to me. When the Phoenix project was announced on MozillaZine, I immediately turned my focus to that instead, and never looked back.

Because the project was still small and new, it was also a good opportunity to get more deeply involved because the signal to noise ratio was higher. Many people in the Mozilla community were still skeptical about Phoenix and preferred the tried and true Mozilla suite. This made the feedback I provided to the Phoenix project much more visible than it had been for the suite, making it a lot more rewarding for me to contribute.

As the project started to shape up with the release of Phoenix 0.3, I found myself heavily involved with things like filing bugs and RFEs, discussing feature implementations with developers, and, most often, answering questions from the growing number of users of Phoenix. As this consumed more and more of my time, I realized that there wasn’t a centralized place for people to get help with Phoenix. I viewed this as my opportunity to finally give something meaningful back to the project, and spent a couple of afternoons creating a small site called Phoenix Help. It was also a more meaningful way to develop my HTML/CSS coding skills compared to creating a website for, say, a Brood War clan (let’s call it UU).

Phoenix Help was very small and seemingly insignificant, but it was quickly noticed and appreciated by fellow community members in the MozillaZine forums. I especially remember getting my first personal e-mail from Asa Dotzler thanking me for doing what I did and encouraging me to continue the great work. This meant a lot for my motivation, because it was a confirmation that what I was doing was appreciated.

Before I knew it, people were linking to my site from all sorts of places (starting with Phoenix 0.5, even the release notes linked to it!), which made it even more important for me to ensure that the site looked good, was easy to use, and that the content was up to date. I was, in fact, responsible for the support site of Phoenix — I “owned” that part of the Phoenix project!

To wrap up, there were several things that motivated me to stay active in the Mozilla community:

• A belief in the mission of the project — to create a web browser that supports and promotes the use of open standards
• An interest in the technology — initially with the Gecko logo as my hook
• The feeling of belonging in a community of people with similar interests
• The desire to give something back to a project that gave (and still gives) me the best browser in the world for free
• The experiences gained by managing a website — HTML, CSS, server configurations, and perhaps most importantly, the English language
• The recognition and respect from Mozilla project members for my contributions
• The pride of being responsible for an important piece of the project

When I look at this list, I realize that it’s impossible to point to one particular motivator for community members, and that everyone probably has their own unique list. More personally, I also note that my motivation model today is the exact same as it was when I got involved seven years ago.

Despite the fact that the list is based on my personal experience, I think that all of the motivators could be taken into consideration for anyone trying to build or grow a community. Depending on the project, some things might be more important than others, but they all affect your community:

Tree Climbing Cat by mokwai

• Does your project add value to people using it? Do people feel like they are making a difference by contributing?
• Is your technology cutting-edge? Is it solving a unique problem? Is your project making people feel “wow, I want to be part of that!” or “I’d love to learn more about that”?
• Is your existing community friendly, welcoming and collaborative? Are tasks and discussions communicated in the open? Do people in your community have fun together?
• What kinds of contributions are welcomed? Does your project offer different ways to get involved?
• What’s in it for the contributors? Aside from the positive feeling of making a difference, do they gain relevant experiences by contributing to your project?
• Do you reach out personally to community members and make them know that their contributions are appreciated? Do you have automated systems in place to show the impact contributors make (e.g. a karma system)?
• Is your project modularized enough to allow people to take ownership of parts of the project?

There you have it — my first attempt to unwrap the mystery of building and growing communities. Is this helpful? Do you have similar experiences? I would love to hear what you think!

Huh, I’m still a bit late in blogging this but I don’t wanna miss it because it’s really important…

With a bit more then a year development Firefox 3.5 has been officially released 2 days ago. It contains tons of new stunning features like native video support, a private browsing mode, a jitted JavaScript engine, and many more. See the official release notes. For a quick overview you can also watch this video.

I’m in London for the next few days and would love to grab a drink with any community members be you Mozilla, CouchDB, Python, Windmill, JavaScript or just plain old coffee, whisky or beer geeks

Although I got into the mozilla project through en-user documentation and support around 2001, I really got involved in Web localization in 2003 when I started to build a Spanish Mozilla community around the Mozilla Suite and I convinced Bob Clary (who also gave me my canconfirm rights in bugzilla, thanks for that!) to publish a page in Spanish on mozilla.org so as to promote Tech Evangelism activities in Spanish.

That was the first non-English page on an official mozilla site ever and the funny thing is that... this page is still online! 

We are now in July 2009 and we just shipped Firefox 3.5 in more than 70 languages, all with a set of in-product pages hosted on mozilla.com. But more than in-product pages, we now have with this release a localized home page on mozilla.com for ALL of our locales!

Now that the release is done and millions of users are downloading the best version of Firefox ever every day, I have some time to thank all of the people that have made such an achievement possible.

Thank you to our localizers first, without them, the Mozilla project would not have the international outreach it has and I really think that our localizers are way more than translators, they are involved in every corner of mozilla activities, from code, to marketing and documentation. It is a privilege for us to work with people having so many skills and passionate about FLOSS and the open web!

Thank you also to the rest of the l10n-drivers team (Seth, Axel, Stas, Gandalf...) and thank you to Delphine who did an awesome job with QA of all of the localized pages over the past weeks on our sites!

Happy international browsing

Pascal

Anne van Kesteren: “Opera has announced support for Ogg Theora and Vorbis“

That’s right, the WHATWG accepts secret feedback.

But… I thought secrets were bad.

Something must have changed. Secrets seem to be OK now. What am I missing?

Those who read this blog may remember that we are trying to finalize a version of Firefox in Swahili.  As it happens now and again, we have two groups who have completed translations at nearly the same time.  The l10n-drivers team is now trying to find the most judicious solution to the problem: determining fairly which translation is best and shipping that.  Amazingly, the differences between the the strings for the two localizations number in the thousands, and properly evaluating the discrepancies is a sizable undertaking for us to find the better version of the two.  If you’d like to see the existing diff, comment here and we’ll send it your way.  Now that we have a finalized Firefox 3.5, I’ve asked each team leader to update the strings in their language pack for final evaluation and we’ll prepare the final diff.

Sadly, amidst all we have done to ship Firefox to seventy-five locales, it was frustrating to read a blog post from one person suggesting that Mozilla’s l10n-drivers team is playing politics when it comes to shipping the Swahili version.  If it needs to be made explicitly clear, we are in the business of shipping excellent localized software to as many locales as possible.  If our team allowed politics to disrupt prudent judgment, I am not sure we would scale at all.

In his post, huarya writes, “The Mozilla people want to play nice with everyone instead of giving priority to the team that has actually showed results, real result!”.  I responded extensively in the comment thread, an d here is a copy of my lengthy response for those who care to read it:

huayra:  I’m not sure if we have ever spoken personally, so it seems a bit careless to suggest that we are playing politics.  If we have spoken via email or IRC, then my apologies.  You can find me on irc.mozilla.org, nick: sethb.

今夜リリースされる Ubiquity の最新版、0.5 に備えて日本語で Ubiquity のスクリーンキャストを作ってみました。 Ubiquity 0.5 は特に多言語化を重視したリリースで、 Ubiquity 内蔵のコマンドが日本語とデンマーク語で使えるようになっています。是非インストールしてみてください！

追伸： ７月３日現在、 Ubiquity 0.5 のリリースを遅らせる方向になったので、残念ながら今日はリリースされません。是非リリース後インストールしてみてください。

Ubiquity 0.5 日本語紹介ビデオ from mitcho on Vimeo.

As Ubiquity 0.5 will be released soon (Thursday morning in Mountain View), I decided it was a good time to put together a screencast in Japanese demoing the use of the new Japanese parser and commands.

Related Posts

1. Foxkeh demos Ubiquity Parser: The Next Generation
2. Changes to Ubiquity Parser 2 and the Playpen
3. A Demonstration of Ubiquity Parser 2

Related posts brought to you by Yet Another Related Posts Plugin.

I'm in the process of working on, and improving, test suite support in TestSwarm (an upcoming project of mine). However, there isn't a lot of information on which unit testing frameworks developers actually use to test their code (whereas there is more information on which JavaScript libraries are used).

It will be of great help to me if you could quickly fill out the question below. I will release the results of the survey as soon as possible. Thanks!

» Which JavaScript Unit Testing Frameworks do you use?

Loading...

More information on the frameworks listed above:

• JSUnit
• Selenium Core
• JSSpec (MooTools)
• UnitTestJS (Prototype)
• QUnit (jQuery)
• DOH Unit Testing (Dojo)
• YUITest 2
• YUITest 3
• Mochitest
• ScrewUnit
• JsUnitTest
• jsUnity
• JsTestDriver
• Crosscheck
• Env.js
• FireUnit

Where's the action these days? I'm currently on Dopplr but have had TripIt invitations. Where are most people in the Mozilla community? A particular one, or both? I hear TripIt parses your emails from Expedia (which Mozilla uses) and other such places, which would be a time-saver. But migrating everything over would be a pain. I guess this is my first experience of potential social networking data migration anxiety. Open data FTW!

Please declare interests such as board seats or shares ;-)

We’ve just launched Firefox 3.5, and we’re incredibly proud. Naturally, we have engaged in plentiful Mozilla advocacy — this site is, amongst other things, a vehicle for showcasing the latest browser’s new capabilities. We like to think about this release as an upgrade for the whole World Wide Web, because of the new developer-facing features that have just been introduced into the web platform. When talking about some of the next generation standards, the appearance of the number “5″ is almost uncanny — consider HTML5 and ECMAScript 5 (PDF). The recent (and very welcome) hype around HTML5 in the press is what motivates this article. Let’s take a step back, and consider some of Mozilla’s web advocacy in the context of events leading up to the release of Firefox 3.5.

Standardization of many of these features often came after much spirited discussion, and we’re pleased to see the prominent placement of HTML5 as a key strategic initiative by major web development companies. Indeed, exciting new web applications hold a great deal of promise, and really showcase what the future of the web platform holds in store for aspiring developers. Many herald the triumphant arrival of the browser as the computer, an old theme that gets bolstered with the arrival of attractive HTML5 platform features that are implemented across Safari, Chrome, Opera, and of course, Firefox (with IE8 getting an honorable mention for having both some HTML5 features and some ECMAScript, 5th Edition features).

Call it what you will — Web 5.0, Open Web 5th Generation (wince!), or, (R)evolution # 5, the future is now. But lest anyone forget, HTML5 is not a completed standard yet, as the W3C was quick to point out. The editor doesn’t anticipate completion till 2010. The path taken from the start of what is now called HTML5 to the present-day era of (very welcome) hype has been a long one, and Mozilla has been part of the journey from the very beginning.

For one thing, we were there to point out, in no uncertain terms, that the W3C had perhaps lost its way. Exactly 5 summers ago (again, with that magic number!), it became evident that the W3C was no longer able to serve as sole custodian of the standards governing the open web of browser-based applications, so Mozilla, along with Opera, started the WHATWG. Of course, back then, we didn’t call it HTML5, and while Firefox itself made a splash in 2004, the steps taken towards standardization were definitive but tentative. Soon, other browser vendors joined us, and by the time the reconciliation with W3C occurred two years later, the innovations introduced into the web platform via the movement initiated by Mozilla had gained substantial momentum.

The net result is a specification that is not yet complete called “HTML5″ which is implemented piecemeal by most modern browsers. The features we choose to implement as an industry are in response to developers, and our modus operandi is (for the most part) in the open. Mozilla funds the HTML5 Validator, producing the first real HTML5 parser, which now drives W3C’s markup validation for HTML5. That parser has made its way back into Firefox. It’s important to note that capabilities that are of greatest interest (many of which are showcased on this blog) are not only developed within the HTML5 specification, but also as part of the W3C Geolocation WG, the Web Apps WG, and the CSS WG.

The release of Firefox 3.5, along with updates to other modern browsers, seems to declare that HTML5 has arrived. But with the foresight that comes with having been around this for a while, we also know that we have a lot of work ahead of us. For one thing, we’ve got to finish HTML5, or at least publish a subset of it that we all agree is ready for implementation, soon. We’ve also got to ensure that accessibility serves as an important design principle in the emerging web platform, and resolve sticky differences here. Also, an open standard does not an open platform make, as debates about web fonts and audio/video codecs show. We’ve got a lot of work ahead of us, but for now, 5 years after the summer we started the ball rolling, we’re enjoying the hype around (R)evolution Number 5.

Looking at the people who moved to FF3.5.0 yesterday:

• 65% downloaded the FF3.5.0 installer and installed from it
• 35% manually did Help->CheckForUpdates

That is a large percentage of people doing CheckForUpdates.

Considering this was our first time having Major Update available on release day, and considering there was no user prompting of this new major update ability, I found these percentages quite delightfully stunning.

This just in…

<othermaciej> sayrer: the normal definition of “open stanard” doesn’t automatically imply royalty-free licensing
<jcranmer> http://en.wikipedia.org/wiki/Open_standard disagrees
<jcranmer> “The term “open” is usually restricted to royalty-free technologies”
<jcranmer> (2nd para)
<sayrer> but that was written by hippies, obviously
<jcranmer> “The definitions of the term “open standard” used by academics, the European Union and some of its member governments or parliaments such as Denmark, France, and Spain preclude open standards requiring fees for use, as do the New Zealand and the Venezuelan governments.”
<sayrer> othermaciej: how about this: proprietary is where you pay
<othermaciej> wikipedia seems to disagree with actual standards orgs (as stated in later paragraphs)

That’s right folks, standards orgs producing patent-encumbered standards claim their standards are open. Clearly, a fair and balanced approach is called for.

Python GDB Rocks!

I wanted a non-painful way to figure out what’s causing bonus file IO. I’ve noticed that gtk likes to open files, but I didn’t have the exact details. So I grabbed python gdb, and with some tips on syscalls from gdb old-timers managed to produce a report to assign blame for open()ing files to relevant Mozilla functions.

Other than the gdb-hating syscalls issue, achieving this was simple

1. Compile python-enabled gdb(Next set of distribution releases should have it..I hope)
2. Define a new gdb command in a python file. I called mine “taras” for lack of a better name.
3. Set a breakpoint, attach your command to it. :
   break open
source -p /path/to/your/script.py
command 1
taras
end
4. Have the script walk the backtrace to figure out the filename and the last Mozilla function. Log the info, issue gdb continue command.
5. Print out a report and profit:
   python report()

Here is my script. The only nasty part here is that I had to read the filename out of a register (i’m on amd64, on 32 it’d be $esi instead of $rdi) because gdb doesn’t deal well with system calls.

I’ve never throught it would be this fun to use gdb. I always thought debuggers should be scriptable, thanks to Tom Tromey (lots of gdb tutorials on Tom’s blog) and any others who finally made this a reality.

The “Sandbox Model” addons.mozilla.org uses to organize and review add-ons was first announced almost 3 years ago. Since then, we’ve made a number of changes based on user feedback that, in my opinion, have greatly improve the experience of finding and installing add-ons that haven’t been officially reviewed yet.

Today, the main feedback concerning the review and distribution process of add-ons is:

• developers feel it takes too long for add-ons to be reviewed, and
• users and developers want to receive updates to add-ons that they have installed that haven’t been reviewed yet

It’s important for us to balance our desire for all add-ons to be discoverable and easy to install with the need for security measures for add-ons that haven’t been reviewed yet.

After taking many of these issues into account, I’ve come up with a proposal for removing the public and sandbox classifications on the site and moving to a more flexible, comprehensive trust system based on everything we know about an add-on. If you’re interested in the review process and distribution of add-ons, please read the proposal and give us your feedback, preferably in this newsgroup thread.

ShareThis

MozQA is holding a Security Testday for Firefox 3.5 on Friday July 10th! Security is something Mozilla takes very seriously.  We have recently updated our security test cases and added some new ones for Firefox 3.5. Our community representatives will be available through IRC Chat ( channel #testday on irc://irc.mozilla.org ), QMO forums as well as the dev-quality newsgroup to help with any of your questions/comments/suggestions. So, if you're interested, come on by anytime between 7AM to 5PM PDT that Friday!

For more information on this event, please see the event page

getfirebug.com has Firebug 1.5a7. This release has one new small feature for users who have sites that generate unique URLs: “Activate Same Origin”. When this option is on, all pages with the same “origin” as an active page will be active. So, for example, if you open Firebug on bar.foo.com, then visiit foo.com or baz.foo.com, Firebug will be open. (This is close to the same-origin policy used by the browser).

Also in this version are some important bug fixes:

• Issue 1894: CSS-edit removes declaration if page with specific javascript.
• Issue 1879: nsIStreamListener.onDataAvailable throws exception
• Issue 882: console.log() reports wrong source file and line number

All of this will appear in Firebug 1.4.0, “soon”. Note that if you install 1.5 it should work well but updates will begin to diverge from 1.4 and at that point it will be, well, ‘alpha’ quality.

jjb

Please post followups to the newsgroup.

Maciej Stachowiak: “I believe the wide availability of H.264 hardware is in part because H.264 was developed through an open standards process that included the relevant stakeholders.”

We’ve deployed our new editor plugin on the Mozilla Developer Center this afternoon. It currently doesn’t do a lot, but what it does is — at least for me — very nice.

When you open the editor on MDC, the table of contents sidebar now disappears, allowing you to use nearly the full width of your browser window for editing the article’s content. When you close the editor (either by saving your change or canceling the editor), the sidebar returns automatically.

This is especially helpful because the sidebar would often get in the way while editing tables and other wider formatted content, including code samples.

Now that Firefox 3.5 is out the door, I plan to ramp up work on back-end stuff even further, including adding more capabilities to our plugins; in addition, I’m gearing up on some organizational work, and talking with Mindtouch about implementing some scripts to help automate more administrative tasks.

We recently released 20 new digital gifts into the Facebook ecosystem.  These cute little icons are part of the  Mozilla Firefox collection that launched last year through the Free Gifts application - conceived by Zach Allia and later transitioned over to SGN.  Exchanging digital gifts has long been a popular activity on social networks, and thousands of Firefox gifts have been sent so far.  If you’re interested, the total numbers per icon are reported on a basic stats page, here (Foxkeh is #1, with over 8,000 gifts sent).  Thanks to Shervin Pishevar, Chris Henley, and Gabriel Stock from SGN for their help on this.  Happy gifting!

I keep my phone in my pocket. This has the (un)fortunate side effect of putting the entire internet in my pants. When I get a call, I have to do a little dance to slip the phone out of my pocket and in to my hand.

I’m one of those people who thinks its rude to answer the phone in the middle of a conversation. It’s worse when it’s during dinner. It’s even border-line rude to just check the phone to see whose calling before slipping it away. I want to know whose calling before I go pocket diving.

Having my phone read out the caller’s name isn’t a tenable solution: I’d don’t want to broadcast that information to everyone near me. Imagine the embarrassment of being on a date and having your ex’s name announced by your phone to the room at large. Or worse, “Mom” being blared in the middle of your slam poetry reading. We’re going to need a more local solution.

I generally keep my phone on vibrate; it’s less intrusive that way. Given a name, it’s not difficult to deduce its basic constituent phonemes (every text-to-speech program does it). Here’s the thought, have the vibrator buzz out the phonemes of the caller’s name. The name Alexis, would be “br br brrr” and Jenny would be “Brr brr”, and Dan would be “bRrr. Imagine it as the sound of trying to say someone’s name without opening your mouth, complete with pitch and loudness modulation (which can be controlled with vibration speed and strength).

Playing around with a toy implementation, the mapping seems to be fairly natural. Learning the feel for a name is close to instant.

I know what your thinking, though: With my hundreds of contacts, how can I possibly differentiate them all from the buzz patterns?

The answer is that you don’t need to.

Most of us get calls regularly from less than 10 people. On Facebook, where the cost of communication is significantly lower than placing a call, an average man has two-way communication regularly with only 4 people. For women, that number is 6. (Data from Primates on Facebook). Learning to differentiate even 10 buzz patterns that feel like the way a name sounds is easy. That covers 90% of your use cases. And keeping you from needing to take your phone out of your pocket 9 out of 10 times is a big win.

Just a thought. It doesn’t bother you when it doesn’t work, doesn’t require you to go through a setup process to choose a ring/vibrate for each person, and is quick to learn. Plus, it gives the phone a bit of emotional impact (think Pixar).

Any other solutions?

Location:
Mozilla Headquarters
650 Castro Street, Suite 300
Mountain View, CA 94041

Start time: 6:30 PM PST. We will have pizza and mingle and the talk will start promptly at 7 PM

If you arrive after 7 PM you will need to call 650-903-0800 x214 to get into the building as the 650 Castro Street lobby doors lock at 7 PM.

Street parking is available on both Castro and Church Streets, as well as directly behind the building.

To say that the SUMO knowledge base is just a wiki really doesn’t do it justice. While it’s very easy to start contributing to the knowledge base and simply assume that it works just like many other wikis (e.g. Wikipedia), there are a number of characteristics of SUMO tailored toward user support which make it different. This can be both a blessing and a curse. We need to understand how SUMO is different; but once we are familiar with it, the community has better tools to provide better user support.

If you’re a new knowledge base contributor, please read our new How we are different page, which lists the differences between SUMO and other wikis and gives an overview of why we are different. New knowledge base contributors will also be able to find a link to that page in our introduction to contributing to the knowledge base.

This is also part of our response to localizer feedback, which we have been continually gathering from active SUMO localizers. Remember that if you are a SUMO localizer and would like to meet with us, just contact us on this blog or post in the Contributors forum.

This post is from Doug Turner who has previous written about Geolocation. Doug works on Mozilla’s mobile project.

XMLHttpRequests (XHR) can be either synchronous or asynchronous. Although most people use asynchronous requests there are instances where you might want to use a synchronous request. That is, wait until the XMLHttpRequest call completes to continue executing JavaScript. In Firefox 3 and earlier the browser would still fire timer events and respond to input events during a synchronous XHR request. In Firefox 3.5 and later input events such as mouse moves and timeouts will be suspended until the synchronous request completes. This allows the synchronous request to block.

For example:

function hello() {
     alert(“hello”);
}
 
setTimeout(hello, 20);
 
var req = new XMLHttpRequest();
req.open('GET', 'http://www.mozilla.org/', false);
req.send(null);

Prior to Firefox 3.5, it was impossible to determine if the “hello” function would be invoked during or after the XHR request. This led to all sorts of timing issues in web applications that used synchronous XHR requests.

The solution to this problem has been to delay input events and timeouts until after “req.send” returns.

For more information see the two bugs on the issue.

(This is a repost of an article I wrote for hacks.mozilla.org)

CSS Media Queries were originally a proposal submitted to the CSS Working Group by Opera Software and are now implemented in Firefox 3.5. In short, Media Queries extend the media declaration attached to a stylesheet to allow matching based on the rendering device's intrinsic properties. 

Let's take a link element declaring a stylesheet inside an HTML document:

<link rel="stylesheet" type="text/css" href="http://www.glazman.org/weblog/dotclear/index.php?post/2009/07/01/style.css"
 media="screen">

<link rel="stylesheet" type="text/css" href="http://www.glazman.org/weblog/dotclear/index.php?post/2009/07/01/style.css"
 media="screen and (max-width: 300px)">

Available properties include viewport's width and height, device's width and height, orientation (portrait or landscape),  viewport's aspect ratio, device's aspect ratio, colormap, resolution and type of device.

It's then very easy to have one single web page ready for consumption on a wide variety of devices, ranging from mobile devices to monochrome tty displays.

Click here to see the demo and don't forget to resize your window from 100px-wide to 900px-wide to see it in action (WARNING: this link opens a new window without toolbars because toolbars could block the size of a viewport above roughly 400px...)

Tristan Nitot of Mozilla Europe will be hosting a live chat on the Web User website (www.webuser.co.uk) on Friday, the 3rd of July at 12:30 BST (that's British Standard Time). He will be answering questions about the recent Firefox 3.5 launch and the floor will be open to anyone who wants to ask Tristan a question about the browser.

All you need to do to take part in the chat is visit www.webuser.co.uk/livechats at 1230BST on Friday 3 July. Questions and comments will be moderated.

Everybody is welcome to participate.

This demo is from Daniel Glazman who works actively on web standards and is a long-time mozilla contributor.

CSS Media Queries were originally a proposal submitted to the CSS Working Group by Opera Software and are now implemented in Firefox 3.5. In short, Media Queries extend the media declaration attached to a stylesheet to allow matching based on the rendering device’s intrinsic properties.

Let’s take a link element declaring a stylesheet inside an HTML document:

<link rel="stylesheet" type="text/css" href="style.css"
      media="screen">

Now imagine you want this stylesheet to apply to the document if and only if the width of the content window is less than 300 pixels… CSS Media Queries make it simple to declare:

<link rel="stylesheet" type="text/css" href="style.css"
      media="screen and (max-width: 300px)">

Available properties include viewport’s width and height, device’s width and height, orientation (portrait or landscape), viewport’s aspect ratio, device’s aspect ratio, colormap, resolution and type of device.

It’s then very easy to have one single web page ready for consumption on a wide variety of devices, ranging from mobile devices to monochrome tty displays.

When viewing the demo, please don’t forget to resize the window from large to very very small (less than 100px!) to see it in action.

View the Demo in Firefox 3.5

Loading via planet, RSS or a reader without JavaScript? Click here instead.

Many people use their hosts file for resources blocking purposes, especially against ads or known malicious sites.

Since your hosts file takes precedence over your DNS in domain name resolution, you can redirect undesired domain to invalid IP addresses, saving both bandwidth and CPU because resolved IPs are cached.

Unluckily, most information sources about this useful technique, including the Wikipedia article above, instruct the reader to use 127.0.0.1 (the local loopback IP) as the dead-end destination, rather than a truly invalid address such as 255.255.255.0. This is not very smart, especially if you installed a web server on the loopback interface (like many web developers do), because you’re spamming it with dummy requests whenever you browse an ad-laden web site.

Furthermore, I’m currently receiving several reports about ABE warnings popping up everywhere. If you read my post about ABE yesterday, you know that it ships with a built in “SYSTEM” ruleset containing just one rule which alone implements the whole LocalRodeo functionality:

# Prevent Internet sites from requesting LAN resources.
Site LOCAL
Accept from LOCAL
Deny

Such a rule blocks any HTTP request for resources placed in your local network, including localhost (127.0.0.1) and any other LAN IP, unless it is originated from your local network as well. This protects your internal servers and devices (e.g. routers and firewalls exposing web interfaces) against CSRF and XSS attacks performed from the internet.

As a side effect, though, if you’re redirecting arbitrary hosts to 127.0.0.1, you’ll get bombed by a storm of ABE warnings whenever those sites are linked from external web sites. The solution is simple: just open your host file and replace 127.0.0.1 with 255.255.255.0 everywhere it’s used to block something, but being careful to keep 127.0.0.1 on the localhost entry and other really local domains, if any.

Feel the Shiretoko Shock!

So what am I personally most excited about in the new Firefox? Well, I have no uses for Private Browsing Mode - I think porn is a terrible corruption of God's design for sexual relationships, my personal medical condition that I research is by no means a secret, and I don't share my computer with anyone anyway. The security UI improvements are cool and well worth having, but I'm not going to get phished any time soon. It's wonderful that we're now in even more languages, but I don't speak any of them!

So really, I'm just waiting for sites to take the excellent technical and standards changes and build cool new stuff I can use. Web designers, what are you waiting for? :-)