Ajaxian

Today we’re calling on industry, higher education and people from around the world to get involved and share their ideas and expertise as we collectively explore and design future directions for the Web.

You don’t have to be a software engineer to get involved, and you don’t have to program. Everyone is welcome to participate. We’re particularly interested in engaging with designers who have not typically been involved with open source projects. And we’re biasing towards broad participation, not finished implementations.

We’re hoping to lower the barrier to participation by providing a forum for surfacing, sharing, and collaborating on new ideas and concepts. Our goal is to bring even more people to the table and provoke thought, facilitate discussion, and inspire future design directions for Firefox, the Mozilla project, and the Web as a whole.

Flash can get to “ubiquitous†across the entire web with new capabilities in roughly 18 months and the Open Web faces a best case replacement time-frame of 5 years.

Reducing that differential from 42 months to zero is now the defining challenge of the Open Web. HTML is back in the hunt. Time to see how fast we can teach it remember the new tricks we’re so eager to teach.

One of our most significant investments is in a feature called Loosely-Coupled IE (“LCIEâ€), which is an architectural attribute that helps isolate different parts of the browser from each other, most notably, the frames from the tabs. LCIE is the foundation that we have built a few of our features on including Automatic Crash Recovery of which I expand on below.

For Beta 2, we added the following changes:

Frame Process Merging

To help improve startup performance, we have reduced the number of processes that we start. Instead of firing up two processes every time you launch the browser (one for the frame and one for your tabs), we now only fire up one frame process the first time you launch IE. Subsequent launches will only start a new tab process or make a new tab in an existing tab process.

For users that are accustomed to browsing websites in multiple “sessionsâ€, for example if you want to log in to multiple email sites simultaneously, you can specify the “-nomerge†command line option to disable this feature.

More tab processes

It turns out that the vast majority of all IE sessions contain three or fewer tabs. Accordingly, in Beta 2 we try to give users three efficient tab processes. This is contingent on the user’s computer capabilities, but the more capable a computer is, the more processes we will use, up to a point. Adding more processes gives users much better isolation in the event of a failure. If each tab is in its own process, websites are completely isolated from each other.

Virtual tabs

We have also added the internal capability to “hot swap†the process from underneath a tab. Previously, Protected Mode worked on a per-process basis. For example, say you add a website to your trusted sites in IE7. If that site links to another site that is not in your trusted sites, it will cause you to switch browser windows when you click the link.

We improved this in IE8 Beta 1 with LCIE when we split the frame from the tabs. With the split we can create a new tab in the same window and switch you to that tab as opposed to being “punted†to a new window.

Virtual tabs lets you navigate across Protected Mode in the same tab since we just switch the process under the tab to the correct integrity level. This is really just “UI-sugar†– virtual tabs do not impact security or protected mode in any way, other than to make it more convenient to transition between protected mode on/off.

LCIE's capability of isolating different parts of the browser coupled with more tab processes and virtual tabs will improve the performance and overall reliability of Internet Explorer.

I've been working on a native Canvas implementation for IE based on the same rendering core that's in Firefox.

With an object tag, a bit of CSS, and (to work around another IE bug) a single line of script, <canvas> elements in HTML just work. I'm excited that this experiment is working out, because lack of Canvas support in IE is one of the reasons people skip Canvas and instead turn to Flash and other plugin technologies.
</canvas>

Pushup is an effort to push the web forward by helping users update their outdated browsers. Give your users a better web experience today by installing Pushup on your domain!

I built a loop benchmarking test suite for different ways of coding loops in JavaScript. There are a few of these out there already, but I didn't find any that acknowledged the difference between native arrays and HTML collections. Since the underlying implementations are different (HTML collections for example lack the pop() and slice() methods, etc), benchmarks that don't test against both are probably missing important information.

My suspicions were confirmed. Accessing the length property is more expensive on HTML collections than on arrays, depending on the browser. In those cases, caching it made a huge difference. However, HTML collections are live, so a cached value may fail if the underlying DOM is modified during looping. On the other hand, HTML collections will never be sparse, so the best way to loop an HTML collection might just be to ignore the length property altogether and combine the test with the item lookup, since you have to do that anyway:

These profiles are meant to provide a picture of what the memory behavior of popular browsers is over a period of time, not to provide absolute benchmark times. Firefox 3.0 shows memory usage that is significantly lower than Firefox 2, which also does very well. Here is a summary of my results.

Single Window Browsing Mode (General Preferences). Actually this is more correctly called “TargetedLinksCreateTabs†and means that any website which attempts to spawn a new browser window will create a new tab in the current window instead. The user may still create new windows with cmd-N.

True Full Screen Browsing Mode. cmd-opt-F. (Window menu -> Toggle Full Screen Mode)

Change to Embedded SSBs. Now they can be made to obey your “Spaces Behavior†preference (appear in all or not). This is cool cuz you can set a different Embedded SSB in each Space for a different background in each. Unfortunately, this means that by default Embedded SSBs don’t work with Expose quite the way I have demonstrated. However, you can reclaim that Expose behavior by changing the Spaces Behavior setting to “Windows Appear in All Spacesâ€Â

Thumbnail Plug-in: Significantly improved load time/UI response time performance, when refreshing the current page to reload the thumbnails, the selected index is preserved, and adding built-in URL Pattern for Microsoft’s live.com search engine.

When Mozilla developers decided to incorporate the Cairo subsystem and build a new graphics layer from scratch, they also decided to completely rework the system that renders text in the browser.

Text is an incredibly important part of the Web. While graphics, audio, and video are increasingly common, we still spend the majority of our time on the Web just reading stuff. All the words you read in a web browser are rendered using a font which contains a set of glyphs used to form individual letters. For more simple written languages there may be a straightforward one-to-one mapping of characters to glyphs, but for more complex languages, one glyph may represent multiple characters.

Touch. This concept prototype for Firefox mobile (code name Fennec) is being designed for a touch screen. Why not multitouch? Because Firefox should be able to run on the least common denominator of touch devices. Especially for touch-enabled interfaces direct manipulation is key. Along that line of thought, the interface should be operable with a finger. Switching between input methods is time-consuming and annoying, so the user shouldn’t have to switch to a stylus or other secondary form of input. Firefox will work on non-touchscreen devices, but that’s out of scope for this demo.

Large targets are good. The same fingertip that controls the interface takes up between 1/5th to 1/10th of the vertical/horizontal height/width of the mobile touch-screen. In other words, fingers are fat: hitting small targets is like trying to touch-type with your elbow. All actions should be represented by targets that are large enough to be fast, easy, and (at the very least) not aggravating to hit.

Visual Momentum and Physics are compelling. Nothing shouts “sexy!†like pretty animations and a physics engine. Beyond marketing appeal, there is a strong argument that such physicality helps the user build a mental model of the interface, and that interface physics yields consistency. We are wired to track the movement of things and to be able to remember where they’ve gone, as long as they don’t appear and disappear, which doesn’t happen in the real world. Of course, copying every physical metaphors blindly gets you interfaces like the multi-million dollar blunder that was Microsoft Bob, so we need to select our metaphors carefully.

Typing is difficult. This means we want to minimize the amount of keystrokes required to get anywhere or do anything.

Content is king. With restricted screen size, every pixel counts. As much of the screen as possible should always be dedicated to content, not controls or cruft.

Gates also highlighted Microsoft's flagship Web technology, the Internet Explorer (IE) browser, which has been an asset and a curse for the company over the years. While it allowed Microsoft to secure its dominant position in Web-browsing technology, it also triggered Microsoft's U.S. antitrust woes, something that haunts the company to this day. IE also has taken a hit in the past several years as Mozilla Firefox, an open-source browser, has gained a loyal following, forcing Microsoft to step up development and make its own product more innovative.

Gates revealed that beta 2 of the next version of IE, IE 8, will be available in August. He also stumped for what has been his pet interest during his years at Microsoft -- natural human-interface technology that allows people to interact with computers in ways similar to how they interact with each other. Last week, Microsoft revealed that the next version of Windows, Windows 7, will include touchscreen technology, a fact he mentioned in his talked.

Tucked away in the list of CSS improvements in Firefox 3 is this innocuous-looking feature: “HTML soft hyphens (­) are now supported.â€Â

Soft hyphens are one of those obscure gems that HTML has always supported on paper, but that no one has taken any notice of because browser support has been spotty. With the imminent release of Firefox 3, however, soft hyphens will be supported by all major browsers including Internet Explorer, Safari, and Opera.

So, what is a soft hyphen, anyway?

A soft hyphen is a character of text that is usually invisible. It signals a spot in the text (usually in the middle of a long word) where it would be acceptable to break the line with a hyphen.

Another obscure-but-useful new feature making its way into Firefox 3 after all the other major browsers support it (mostly) is the inline block. When assigned to an element, a display type of inline-block causes the element to be positioned inline (like a span), but the element’s contents are laid out as if the element were a block.

This feature will come in handy in a number of situations in which the float property is currently being used for lack of a better option.

The most interesting fact I discovered is that Safari places no limit
on the number of cookies that can be set per domain. In fact, you can
set enough cookies on the client to cause a server error as the cookie
header can be too long to parse.