Mark PilgrimLiving in a browser

(Googler hat off)

I just spent an hour in Starbucks. (My kid is down the street at a Chinese class.) In the past hour, I’ve checked my email, read news, caught up on the HTML5 mailing lists and IRC chatter, paid two bills, balanced my checkbook, and written this post. Without leaving my browser.

So yeah, Google Chrome OS is gonna be a hit.

Bummer about the whole “only runs apps signed by a private key that Google won’t be sharing with anyone” thing. I’m not thrilled about the prospect of working for a DRM company. Google was in the DRM business once before; it ended with giving everyone their money back, twice. And does anyone honestly believe the first Chrome OS machine won’t be jailbroken within a week? Update: I’m getting conflicting reports about whether retail (non-developer) Chrome OS hardware will include a way to run unverified software. I’m locking this discussion thread until I can confirm this important detail.

On the other hand, computer maintenance sucks gargantuan donkey balls, and normal people don’t care about root. If you accost a random person on the street and ask them if they need root on their operating system to install another browser, and they’ll have three questions for you: 1. What’s root? 2. What’s an operating system? 3. What’s a browser?

Still… if I had root on a Linux netbook, the first thing I’d do is install Chromium and then spend 99% of my time in the browser. So I have to think that Chrome OS is a step in the right direction.

This is an open thread, but I won’t answer any questions on behalf of Google.

AjaxianFull Frontal ‘09: Stuart Langridge on HTML5 Features

Stuart Langridge introduces us to some of the up-and-coming features we're getting with current and future browsers, a nice complement to Robert Nyman's talk, which covered the advanced features of "mainstream" (IE6-compatible) Javascript. After introducing the features that are there today, he also talks about how we can deal with the browser many of us are still having to support.

The Goodies

Here are some of the things we can look forward to. (Having been part of the large crowd who charged the pub across the road at lunch, I was a bit late getting back, so I missed one or two of these.)

Lists

JAVASCRIPT:
  1.  
  2. [1,2,3].every(function()) // run for all items
  3. list.filter() // find elements in the list that pass the function
  4. list.map() // apply function to each item
  5.  

It takes a mental shift to start taking advantage of features like this. "Certain browsers" *cough* don't yet provide these conveniences, but you can take advantage of them straight away. Or another example is the base2 library - use it now and you'll be ready for the time when it's present in all browsers.

Getters and Setters

As our Javascript apps get increasingly bigger and more complex, we need to borrow principles, patterns, and techniques from "real programming". Getters and setters are the kind of thing we'll need more of. More generally, we'll need to be in the mindset that we're building APIs to components, which others might use; not just an individual making a one-off web app. Stuart shows a couple of techniques for getters and setters: (a) manually defined; (b) using

Storage

We can now do global storage - globalStorage works similarly to cookies. "Like cookies turned up to 11".

JAVASCRIPT:
  1.  
  2.   globalStorage["kryogenix.org"].visits = visits+1
  3.  

He notes that like XHR, Microsoft did it a long time ago with userdata.

There is also the possibility of SQL and a consistent database API, somewhat supported today but not yet standardised.

Server-Sent Events

HTML:
  1.  
  2. <event -source src="getTime.php">
  3.  
JAVASCRIPT:
  1.  
  2. document.getElementsByTagName("event-source")[0].addEventListener("server-time", eventHandler, false);
  3. function eventHandler(event) {
  4.   alert(event.data);
  5. }
  6.  

Only in Opera right now.

Great. So Do We, Can We, Use it Now or Later?

You can use these features now if you're in a single-browser environment that supports them: app for one mobile; Air app; intranet app (where you've amazingly got Firefox exlcusively on your intranet); HTA. This isn't the sinful act of coding to weird proprietary APIs; it's coding to browsers that happen to support the technologies of tomorrow, today.

The libraries help us get to the future today, as long as they can support APIs compatibly across all the browsers. But it's all a little difficult when the market leader doesn't play ball. Hopefully, Dean Edwards will continue working on Base2 to plug the gaps, but we still have the problem. Around a year ago, it felt like the anti-IE6 might be at a tipping point, but that's died down a bit, and it's not clear how much longer we'll be held back.

What can you do then with IE6? If a number of major websites really held back and stopped supporting IE6, Stuart reckons corporations would upgrade. Imagine what would happen if Google stopped working on IE6...immediate upgrades. Show of hands indicates perhaps 20% of the audience would agree to mass dropping IE6 on their public sites. In Q&A, Stuart later clarifies he's not really proposing an IE6 shutdown switch, more like a helpful suggestion to upgrade.

Silverlight and Flash. Proprietary, not open. If everyone started using Flash, the future is Adobe's future. Let's make it our future instead - we're building the open web. A call to arms for showing strength in numbers.
</event>

Stack Overflow: HTML5Will Visual Studio 2010 support HTML 5?

Since Visual Studio 2010 is slated for release in March of 2010 and HTML 5 is now starting to be used even more widely, I would like to know if Visual Studio will ship with HTML 5 templates, standard controls and support for the more common markup?

A definition for support of HTML 5 would be that any new version of Visual Studio should have similar support for code-completion, validation and markup that is currently supported for HTML 4.01 and XHTML 1.0 and 1.1.

Update From the Visual Web Develolper Team Blog:

HTML 5 intellisense and validation schema for Visual Studio 2008 and Visual Web Developer is for downloading. Follow the instructions posted on the page to install the new scheme. Seems like the Visual Studio Team will be supporting HTML 5 after all.

Stack Overflow: HTML5Google Semantic results question

http://www.google.co.uk/search?q=mark+zuckerberg+crunchbase

Guys, check out that search, in particular the first result's url. Crunchbase.com > People, and thus the people links to the /people section of the site.

How are they achieving it? I know Google algorithm is intelligent and looks for links and then makes the assumptions itself in cases, but is there any particular markup they are using to help Google to make these connections?

W3C Team blogDefault Prefix Declaration

<html> <head> <meta content="HTML Tidy for Linux/x86 (vers 14 June 2007), see www.w3.org" name="generator"> <meta content="Copyright (C) 2007 Henry S. Thompson" name="copyright"> <meta content="text/html; charset=us-ascii" http-equiv="Content-type"> <style type="text/css"> @page { size: A4 portrait; margin: 2cm} @media screen { body {width: 20cm; margin-left: auto; margin-right: auto} } body {font-size: 12pt} pre.code {font-family: monospace} pre {margin-left: 0em} ul.nolabel { margin: 0; margin-left: -2.5em} ul.naked li { list-style-type: none } ol ol {list-style-type: lower-alpha} div.ndli { margin-bottom: 1ex } .math {font-family: 'Arial Unicode MS', 'Lucida Sans Unicode', serif} .sub {font-size: 80%; vertical-align: sub} .termref {text-decoration: none; color: #606000} div.toc h2 {font-size: 120%; margin-top: 0em; margin-bottom: 0em} div.toc h4 {font-size: 100%; margin-top: 0em; margin-bottom: 0em; margin-left: 1em} div.toc h1 {font-size: 140%; margin-bottom: 0em} div.toc ul {margin-top: 1ex} .byline {font-size: 120%} div.figure {margin-left: 2em} div.caption {font-style: italic; font-weight: bold; margin-top: 1em} i i {font-style: normal} </style> Default Prefix Declaration </head> <body style="font-family: DejaVu Sans, Arial; background: rgb(254,250,246)">

Default Prefix Declaration

Table of Contents

1. Disclaimer

The ideas behind the proposal presented here are neither particularly new nor particularly mine. I've made the effort to write this down so anyone wishing to refer to ideas in this space can say "Something along the lines of [this posting]" rather than "Something, you know, like, uhm, what we talked about, prefix binding, media-type-based defaulting, that stuff".

2. Introduction

Criticism of XML namespaces as an appropriate mechanism for enabling distributed extensibility for the Web typically targets two issues:

  1. Syntactic complexity
  2. API complexity

Of these, the first is arguably the more significant, because the number of authors exceeds the number of developers by a large margin. Accordingly, this proposal attempts to address the first problem, by providing a defaulting mechanism for namespace prefix bindings which covers the 99% case.

3. The proposal

Binding
Define a trivial XML language which provides a means to associate prefixes with namespace names (URIs);
Invoking from HTML
Define a link relation dpd for use in the (X)HTML header;
Invoking from XML
Define a processing instruction xml-dpd and/or an attribute xml:dpd for use at the top of XML documents;
Defaulting by Media Type
Implement a registry which maps from media types to a published dpd file;
Semantics
Define a precedence, which operates on a per-prefix basis, namely xmlns: >> explicit invocation >> application built-in default >> media-type-based default, and a semantics in terms of namespace information items or appropriate data-model equivalent on the document element.

4. Why prefixes?

XML namespaces provide two essentially distinct mechanisms for 'owning' names, that is, preventing what would otherwise be a name collision by associating names in some way with some additional distinguishing characteristic:

  1. By prefixing the name, and binding the prefix to a particular URI;
  2. By declaring that within a particular subtree, unprefixed names are associated with a particular URI.

In XML namespaces as they stand today, the association with a URI is done via a namespace declaration which takes the form of an attribute, and whose impact is scoped to the subtree rooted at the owner element of that attribute.

Liam Quin has proposed an additional, out-of-band and defaultable, approach to the association for unprefixed names, using patterns to identify the subtrees where particular URIs apply. I've borrowed some of his ideas about how to connect documents to prefix binding definitions.

The approach presented here is similar-but-different, in that its primary goal is to enable out-of-band and defaultable associations of namespaces to names with prefixes, with whole-document scope. The advantages of focussing on prefixed names in this way are:

  • Ad-hoc extensibility mechanisms typically use prefixes. The HTML5 specification already has at least two of these: aria- and data-;
  • Prefixed names are more robust in the face of arbitrary cut-and-paste operations;
  • Authors are used to them: For example XSLT stylesheets and W3C XML Schema documents almost always use explicit prefixes extensively;
  • Prefix binding information can be very simple: just a set of pairs of prefix and URI.

Provision is also made for optionally specifying a binding for the default namespace at the document element, primarily for the media type registry case, where it makes sense to associate a primary namespace with a media type.

5. Example

If this proposal were adopted, and a dpd document for use in HTML 4.01 or XHTML1:

<dpd ns="http://www.w3.org/1999/xhtml">
 <pd p="xf" ns="http://www.w3.org/2002/xforms"/>
 <pd p="svg" ns="http://www.w3.org/2000/svg"/>
 <pd p="ml" ns="http://www.w3.org/1998/Math/MathML"/>
</dpd>

was registered against the text/html media type, the following would result in a DOM with html and body elements in the XHTML namespace and an input element in the XForms namespace:

<html>
 <body>
  <xf:input ref="xyzzy">...</xf:input>
 </body>
</html>
</body> </html>

Planet MozillaState of Mozilla and 2008 Financial Statements

Today we are posting our audited financial statements and tax form for 2008. We have also posted our FAQ. As in past years, I’ll use this event as an opportunity to review both our financial status and our overall effectiveness in moving the mission forward.

Financial

The financial highlights are:

  1. Mozilla remains strong financially despite the financial crisis of 2008. Our investment portfolio was somewhat reduced, but overall revenues remained steady and more than adequate to meet our needs. We continue to manage our expenses very carefully.
  2. Mozilla remains well positioned, both financially and organizationally, to advance our mission of building openness, interoperability and participation into the Internet.

Our revenue and expenses are consistent with 2007, showing steady growth. Mozilla’s consolidated reported revenues (Mozilla Foundation and all subsidiaries) for 2008 were $78.6 million, up approximately 5% from 2007 reported revenues of $75.1 million. The majority of this revenue is generated from the search functionality in Mozilla Firefox from organizations such as Google, Yahoo, Amazon, eBay, and others.

2008 revenues include a reported loss of $7.8 million in investments in the Foundation’s long-term portfolio (approximately 25%) as a result of economic conditions and investment values at the end of 2008. Excluding investment gains and losses, revenues from operational activity were $86.4 million compared to $73.3 million in 2007, an annual increase of 18%.

Mozilla consolidated expenses for the Mozilla Foundation and all subsidiaries for 2008 were $49.4 million, up approximately 48% from 2007 expenses of $33.3 million. Expenditures remain highly focused in two key areas: people and infrastructure. By the end of 2008, Mozilla was funding approximately 200 people working full or part-time on Mozilla around the world. Expenditures on people accounted for roughly 58% of our total expenses in 2008. The largest concentrations of people funded by Mozilla are in the U.S, Canada, and Europe with smaller groups in China and New Zealand and individuals in many parts of the world.

Total assets as of December 31, 2008 were $116 million, up from $99 million at the end of 2007, an increase of 17% to our asset base. Unrestricted assets at the end of 2008 were $94 million compared with $82 million in 2007, a 15% increase. The restricted assets remain the same as last year: a “tax reserve fund” established in 2005 for a portion of the revenue the Foundation received that year from the search engine providers, primarily Google. As noted last year, the IRS has opened an audit of the Mozilla Foundation. The IRS continues to examine our records for the years 2004-2007. We do not yet have a good feel for how long this will take or the overall scope of what will be involved.

Total grants, donations, and contributions in 2008 were approximately $1 million matching the approximately $1 million of 2007. Mozilla supported projects such Mozdev, Software Freedom Conservancy, and accessibility support for the jQuery library, HTML 5 video, and Firebug.

We believe that Mozilla’s financial setting will continue with relative stability. We continue to use our assets to execute on the mission.

Moving the Mission Forward

2008 was another exciting and robust year for Mozilla. Our scope of activities continued to grow, our community of committed contributors and users expanded, our geographical diversity deepened, and our effect on increasing openness, participation, innovation and individual empowerment in Internet life is significant. Here are some examples.

In February we launched Mozilla Messaging to develop Mozilla Thunderbird as well as new possibilities in the broader messaging arena. 2008 was primarily a start-up year for Mozilla Messaging. In 2009 we’re starting to see the Mozilla Messaging team deliver on the promise. The final version of Thunderbird 3 –- a vastly improved product — is due to be released shortly. In addition the initial developer version of Raindrop — a prototype for a new way of integrating different kinds of messages — has been released.

In 2008 we developed a set of two-year goals (the “2010 goals”), setting out major areas we’d like to see the Mozilla project address in 2009 and 2010. The 2010 goals build upon the Mozilla Manifesto, which articulates the values underlying the Mozilla project and our products. Two of these are familiar — openness in general and continued vitality of Firefox. Two are newer: the mobile web and helping people manage the explosion of data around us. These reflect our desire to see the values of the Mozilla Manifesto infused into these areas of Internet life.

We began an on-going process of strengthening some of the Mozilla project’s basic assets. We began broadening our “module ownership” system beyond code to include governance activities. We began a long-overdue update of the mozilla.org website. In September Mark Surman joined as the new Executive Director of the Mozilla Foundation. These activities continued in 2009, along with new Education and Drumbeat programs.

We expanded the scope of our innovation efforts under the “Mozilla Labs” banner. We launched a range of projects including our first Design Challenge, Test Pilot (user testing program), Ubiquity (natural language interface to browser interaction), and a Developer Tools program. We also expanded existing projects like Weave, Personas and Prism. This focus on innovation continues during 2009.

The activities of Mozilla’s support, localization, campus representative and design communities expanded significantly through 2008 and 2009, reaching more people in more ways.

Mozilla continues to grow ever more global. In June 2008 Firefox 3.0 launched simultaneously in 46 languages. A year later, Firefox 3.5 featured 70 languages. In 2008 Firefox became the majority browser in specific countries. This started with Indonesia, which passed 50% in July 2008, and grew to include Slovenia and Macedonia by the end of 2008. Since then, Slovakia, the Philippines, Poland, Hungary, Latvia, Bosnia Herzegovina, and Ghana have joined this group. Our local communities also work with other Mozilla products and activities such as Thunderbird, Seamonkey and Service Week (in 2009).

We intend to continue to invest significantly in global participation.

Product and Competition

The number of people using Mozilla products increased dramatically throughout 2008 and 2009. This user base makes Mozilla relevant to the Internet industry, helping us move the Internet to a more open and participatory environment. It also helps us build public benefit, civic and social value as components of the Internet’s future.

The number of people using Firefox on a daily basis increased from 28 million in 2006 to 49 million in 2007. In 2008 we moved up to 75 million daily users. As of November 2009 the daily number has grown to 110 million, bringing the total number of users to approximately 330 million people.

Our market share rose to approximately 21.69% in December of 2008. This breaks out into U.S. market share of approximately 20.2%, and more than 32% in Europe. Our statistics for Asia are similar, with our own estimates around 20%. Our South American market share rose to 27% by the end of 2008. These numbers have all continued to rise in 2009 as well. In February, 2008 we crossed the half-billion download mark; in July, 2009 we exceeded 1 billion downloads. As of November, 2009 Firefox’s market share worldwide reached 25%.

In June 2008 we released Firefox 3.0, bringing dramatic improvements to the online browsing experience. These improvements included features to help users quickly navigate to favorite websites, manage their downloads more easily, and keep themselves safe from malware attacks. Firefox 3 was downloaded over 8 million times in the first 24 hours, earning Mozilla a Guinness World Record. In June 2009 we released Firefox 3.5, with additional performance and feature improvements. In November 2009 we celebrated the fifth anniversary of Firefox.

Work on Firefox for mobile devices began in earnest in 2008 with the first development milestones released. We expect to release the first product versions late in 2009. The mobile market has many challenges for us, in particular the fragmentation of the development platform (a plethora of operating systems, handsets and carriers) and a market where touching a consumer directly is more difficult. However, the market is beginning to change and a great, open browser will both help that process and benefit from it. We have much more to do, but have laid a good foundation for long-term contribution to the mobile Web.

SeaMonkey remains a vital project with millions of users. Bugzilla continues as a backbone tool for numerous organizations. A revitalized Thunderbird 3 should ship in 2009.

Looking Forward

The past few years have seen an explosion of innovation and competition in web browsers, demonstrating their critical importance to the Internet experience and marking the success of our mission. In 2008 not only did Microsoft and Apple continue developing their web browsing products, but Google announced and released a web browser of its own. Competition, while uncomfortable, has benefited Mozilla, pushing us to work harder. Mozilla and Firefox continue to prosper, and to reflect our core values. We expect these competitive trends to continue, benefiting the entire Web.

The Internet remains an immense engine of social, civic and economic value. The potential is enormous. There is still an enormous amount to be done to build openness, participation and individual opportunity into the developing structure of the Internet.

Hundreds of millions of people today trust Mozilla to do this. This is an accomplishment many thought was impossible. We should be proud. We should also be energized to do more and to try to new things. It’s a big challenge. It’s important.

We’ve made this opportunity real. Let’s go surprise people once again by showing how much better we can make the Internet experience.

Planet WebKitWebKit nightlies support HTML5 noreferrer link relation

WebKit nightlies now support the HTML5 noreferrer link relation, a neat little feature that allows web developers to prevent browsers from sending the Referrer: header when navigating either <a> or <area> elements.  Just add noreferrer in the rel attribute of a link like so:

<a href="www.example.com" rel="noreferrer">noreferrer!</a>

When example.com receives the HTTP request generated by clicking this link, the HTTP Referer field will be empty, as if the user had navigated from about:blank.

When rel=”noreferrer” is used in conjunction with target=”_blank”, WebKit will also set the window.opener attribute to null.  This usage is interpreted as a request from the web page author that any scripts on the destination page should be run in a new context, even if the destination page would normally be considered to be of the same origin.

The noreferrer link relation is one of many link relations defined in the HTML5 spec, and the first to be implemented in WebKit.  We hope it will make life a little easier for web developers who have concerns about user privacy and security.

Stack Overflow: HTML5I'm overhauling my blog and … is HTML5 OK?

I'm overhauling my blog (http://gilesvangruisen.com/) and I'm going to be pushing new technologies as much as possible.

I'm a web designer/developer and the browser percentage is as follows: 42% Firefox 39% Safari 7% Chrome 7% IE

Is it OK to use the HTML5 doctype for my "rethunk" site?

I thank you. -Giles :)

HTML5 DoctorHTML5 Doctor Glossary

Over the last few weeks, we’ve been working on something a little special here at the HTML5 Doctor.

You’re obviously here because you’re interested in HTML5. You might even be here because the thought of reading the HTML5 spec on the W3C site gives you nightmares. Well, fear not, for you shall be able to sleep easy once again! We’ve just launched the HTML5 glossary.

The purpose of the glossary is simple: we’re going to give you a breakdown of all the elements within the spec in clear, bite-sized chunks.

glossary

From the screenshot above, you can see that we’ve laid out the page to be as clear as possible (using HTML5, of course). At the top of the page is an alphabetised list of links to individual sections of the glossary. The rest of the page is the list of elements and their descriptions.

glossary3

I’ve labeled the key points of each entry in the above screenshot:

  1. Links labeled “Our Prognosis” refer to an article that one of the Doctors has previously published.
  2. Each entry contains a brief description of what the element represents and its proper (and possibly improper) uses.
  3. We always include a link to the element’s full description in the official HTML5 spec.
  4. Code snippets show contextual examples of the element in an HTML document (shown in the screenshot below).

glossary2

Not every element has a code snippet and “prognosis” link, but we’ll be doing out best to flesh out the glossary with some more examples and elements in the coming weeks.

Be sure to add the glossary to your list of HTML5 resources!

Got a suggestion to help us improve the glossary? Request a missing element or report a problem by leaving a comment below, or head over to the contact page and send us an email.

Share and Save:

Twitter
Digg
Sphinn
Reddit
del.icio.us
StumbleUpon
Technorati
Netvibes
Facebook
Google Bookmarks
FriendFeed
HackerNews
LinkedIn
NewsVine
Tumblr



Stack Overflow: HTML5Which would you prefer? SVG, HTML5 or regen'd-PNG for graphs & charts?

I'm developing a new site that graphs some operational metrics. As such about a dozen charts/graphs will be displayed on the site. I want to be able to have them dynamically scale down (within reason) based upon the size of the browser.

I'm debating the pros/cons of generating these as one of these options:

  1. SVG. Great for scaling but support may have limited support,
  2. HTML5. Clearly a great choice for the future and for FF customers, IE?
  3. PNG. This would require that I regenerate the PNG based upon the size of the DIV &c.

Which is the preferable option? I'm leaning towards PNG just for ubiquitous support, but would like to have client-side scaling. What is the best solution given the state of affairs of SVG and HTML5 canvas support in browsers?

Stack Overflow: HTML5contenteditable's execcommand

this is normal call 'document.execCommand(cmd, null, null);' but as you see it applies to document, how do i make it apply to certain element being edited (Div). problem is when you call 'justifyright',etc it will execute on another divs too.

im testing this in firefox 3.5.5

edit: seems like a bug in firefox, because it works fine in IE8

Mark PilgrimAndroid 2.0 Platform Highlights | Android Developers

"Support for HTML5" -- web database, application cache, geolocation, video

Stack Overflow: HTML5Does Internet Explorer 8 support HTML 5?

Does any HTML5 support in the IE8 betas? Is it on the IE8 roadmap?

Shelley PowersMicrosoft's Proposed Namespace Distributed Extensibility in HTML5

Per Sam Ruby, Microsoft has submitted a proposal for distributed extensibility in HTML5, which features the use of namespaces.

The proposal uses reverse DNS names, but other than those ugly sons-of-bitches, it looks promising. There are some issues, including no support for innerHTML on namespaced elements, because they would end up defined as Element, not HTMLUnknownElement, but I don't think that's going to be a real problem in the wild. More importantly, I believe the proposal would handle the problems I noted in my last writing, about the valid use of namespaced elements and attributes in SVG. The issue with namespaced elements in SVG isn't a made up problem, or one that is unlikely to occur: it is a real problem, it will occur in the future, and it does require real solutions. The problem is not going to go away because Ian Hickson clicks ruby shoes together and murmurs "There's no such thing as namespaces...there's no such thing as namespaces..." This absolute refusal to acknowledge something that has existed on the web for a decade is, frankly, unconscionable.

I wish I could say that the happy campers of the HTML WG are willingly to at least enter into an open and unbiased discussion on the proposal, but I stopped believing in fairy tales, a long time ago. There is contention on this issue (namespaces for distributed extensibility), as noted in the past, in current discussion, in the HTML WG bug database, related to the new RDFa-in-HTML proposal. Needless to say, the WhatWG members have responded in their typically, open and mature manner.

But here's some cold, hard reality for Ian et al: this isn't a proposal from folks like me, who have little say, and no power. This proposal comes from Microsoft. Microsoft, who still maintains a dominant position when it comes to browser use in the world. The HTML5 editor cannot simply ignore the proposal, pretend he doesn't understand it, or rubber stamp it WONTFIX. Not this time.

Printer friendly version

IEBlogAn Early Look At IE9 for Developers

We’re just about a month after the Windows 7 launch, and wanted to show an early look at some of the work underway on Internet Explorer 9. 

At the PDC today, in addition to demonstrating some of the progress on performance and interoperable standards, we showed how IE and Windows will make the power of PC hardware available to web developers in the browser. Specifically, we demonstrated hardware-accelerated rendering of all graphics and text in web pages, something that other browsers don’t do today. Web site developers will see performance gains and other benefits without having to re-write their sites.

Performance Progress. Browser performance involves many different sub-systems within the browser. Different sites – and different activities within the same site – place different loads and demands on the browser.

For example, two news sites might look similar to a user but have very different performance characteristics. Because of how the developers authored the sites, one site might spend most of its time in the Javascript engine and DOM, while the other site might spend most of its time in layout and rendering. A site that’s more of an “application” than a page (like web-based email, or the Office Web Apps) can exercise browser subsystems in completely different ways depending on the user’s actions.

The chart below shows how much time different sites spends in different subsystems of IE. For example, it shows that one major news site spends most of its time in the script engine and marshalling, while another spends most of its time in script and rendering, and the Excel Web App spends very little of its time running script at all.

chart of which IE subsystems different websites spend their time in.  The chart shows that each site has a very different allocation of which subsystems they spend time in.

Note that this chart shows the percentages of total time spent in each subsystem, not relative time between sites. It focuses on just the primary browsing sub-systems and doesn’t include “frame” functionality (like anti-phishing), or third-party software that’s running in the IE process (like toolbars, or controls like Flash). It also factors out networking since that’s dependent on the users network speed. Notice also that a site’s profile can change significantly across scenarios; for example, the Excel Web App profile for loading a file is quite different from the profile for selecting part of the sheet.

The script engine is just one of these browser subsystems. There are many benchmarks for script performance. One common test of script performance is from Apple’s Webkit team, the SunSpider test. The chart below shows the relative performance of different browsers on the same machine running the SunSpider test.

chart of IE, FF, Chrome and Safari performance of Sunspider test.  The IE9 results on sunspider are competitve with FF 3.6, Chrome4 and the nightly webkit build.

In addition to IE7 and the current “final release” versions of major browsers, we’ve included the latest pre-release “under development” builds of the major browsers. We’re just about a month after IE8 was released as part of the Windows 7 launch, and the version of IE under development is no longer an outlier. 

It is worth noting that once the differences are this small, the other subsystems that contribute to performance become much more important, and perceiving the differences may be difficult on real-world sites. That said, we remain committed to improving script performance.

We’re looking at the performance characteristics of all the browser sub-systems as real-world sites use them. Our goal is to deliver better performance across the board for real-world sites, not just benchmarks.

Standards Progress. Our focus is providing rich capabilities – the ones that most developers want to use – in an interoperable way.  Developers want more capabilities in the browser to build great apps and experiences; they want them to work in an interoperable way so they don’t have to re-write and re-test their sites again and again. The standards process offers a good means to that end.

As engineers, when we want to assess progress, we develop a test suite that exercises the breadth and depth of functionality. With IE8, we delivered a highly-interoperable implementation of CSS 2.1 and contributed over 7,200 tests to the W3C. Standards that do not include validation tests are much more difficult to implement consistently, and more difficult for site developers to rely on.

Some standards tests – like Acid3 – have become widely used as shorthand for standards compliance, even with some shortcomings. Acid3 tests about 100 aspects of different technologies (many still in the “working draft” stage of standardization), including many edge cases and error conditions. Here’s the latest build of IE9 running Acid3: 

screen shot of ACID3 test showing a score of 32.

As we improve support in IE for technologies that site developers use, the score will continue to go up. A more meaningful (from the point of view of web developers) example of standards support involves rounded corners. Here’s IE9 drawing rounded corners, along with the underlying mark-up:

screenshot of a box with rounded corners.  each corner is rounded differently.

Another example of standards support that matters to web developers is CSS3 selectors. Here’s a test page that some people in the web development community put together at css3.info; it’s a good illustration of a more thorough test, and one that shows some of the progress we’ve made since releasing IE8:

screenshot of css3.info test page showing many passing test cases.

Community testing efforts like this one can be helpful. Ultimately, we want to work with the community and W3C and other members of the working groups to define true validation test suites, like the one that we’re all working on together for CSS 2.1, for the standards that matter to developers. For example, this link tests one of the HTML5 storage APIs; some browsers (including IE8) support it today, while others don’t.

The work we do here, both in the product and on test suites, is a means to an end: a rich interoperable platform that developers can rely on. 

Bringing the power of PC hardware and Windows to web developers in the browser. The PC platform and ecosystem around Windows deliver amazing hardware innovation. The browser should be a place where the benefits of that hardware innovation shine through for web developers.

We’re changing IE to use the DirectX family of Windows APIs to enable many advances for web developers. The starting point is moving all graphics and text rendering from the CPU to the graphics card using Direct2D and DirectWrite. Graphics hardware acceleration means that rich, graphically intensive sites can render faster while using less CPU. (This interview includes screen captures of a few examples.) Now, web developers can take advantage of the hardware ecosystem’s advances in graphics while they continue to author sites with the same interoperable standards patterns they’re used to.

In addition to better performance, this technology shift also increases font quality and readability with sub-pixel positioning:

96 point Gabriola on a Lenovo X61 ThinkPad at 100% Zoom using GDI (note jaggies):

text "Direct2D" in 96pt Gabriola font using GDI rendering.  The rendering looks somewhat jagged.

96 point Gabriola on a Lenovo X61 ThinkPad at 100% Zoom: Direct2D (without jaggies):

text "Direct2D" in 96pt Gabriola font using Direct2D rendering.  The rendering looks much smoother than how it is rendered in GDI.

Last week, Channel 9 interviewed several of the engineers on the team. You can find videos of the interviews here:

Introduction, and Interoperable Standards

Early look at the Script Engine

Hardware accelerated graphics and text in the browser via Direct2D

While we’re still early in the product cycle, we wanted to be clear to developers about our approach and the progress so far. We’re applying the feedback from the IE8 product cycle, and we’re committed to delivering on another version of IE.

Thanks,
Dean Hachamovitch
General Manager, Internet Explorer

Planet MozillaFirefox Beta 3.6 (revision 3) now available for download

Editor’s note: Mozilla released Firefox 3.6 beta 3 on Tuesday, November 17, 2009. Check out the Mozilla Developer News announcement reposted below for more details.

Last night the Mozilla community released Firefox 3.6 Beta 3, making it available for free download and issuing an update for all Firefox 3.6 beta users. This update contains over 80 fixes from the last Firefox 3.6 beta, containing many improvements for web developers, Add-on developers, and users. More than half of the thousands of Firefox Add-ons have now been upgraded by their authors to be compatible with Firefox 3.6 Beta. If your favorite Add-on isn’t yet compatible, you can also download and install the Add-on Compatibility Reporter – your favorite Add-on author will appreciate it!

The Mozilla community appreciates your feedback and assistance in testing this preview of the next version of Firefox. Your beta software will update itself periodically, and eventually will be updated to the final release itself.

The Beta of Firefox 3.6 / Gecko 1.9.2 introduces several new features for users to evaluate:

Web developers and Add-on developers should read more detail about the many new features in Firefox 3.6 for developers on the Mozilla Developer Center. For the full list of changes since the alpha release, see this list (it’s big).

Please use the following links to download Firefox 3.6 Beta, or visit the beta download page:

As always, the Mozilla community would appreciate hearing about any feedback you have about this release, or any bugs you may find.


Footnotes

Updated: .  Michael(tm) Smith <mike@w3.org>