September 9th, 2010
The Internationalization Core Working Group has just published 6 new articles and updated a further 5 articles and a tutorial to help HTML and CSS authors understand how to work with character encodings on the Web. For instance, there are…
September 9th, 2010
It’s back-to-school season in many parts of the world, so we thought we’d kick off a series of blog posts about cool Chrome extensions that can make life easier for students. These include extensions that helps students keep in touch with friends and family, research and write papers, and be more productive during the school year. Check out the Official Google for Student blog to read about today’s extensions that help students stay connected with friends at school and those back home.
September 9th, 2010
Opera 10.62 has been released as a recommended upgrade offering security and stability enhancements.
Changelogs
Windows / Mac / *nix
Thanks to everyone who helped out with testing! If you are ready for more, we’ve got some nice things coming up on the 10.70 branch in the coming weeks and months.
September 9th, 2010
As we’ve previously discussed, IE9 includes support for HTML5 canvas. You can test it out right now by downloading the latest platform preview. In our testing of sites that use the latest web standards, we are pleased to see that many canvas sites just work in IE9. For those of you using <canvas> on your site, we have two tips to make sure it works properly across browsers and in IE9: use feature detection instead of browser detection, and use <!DOCTYPE html>.
Be sure to use feature detection instead of browser detection
If you are using browser detection, such as automatically falling back to a non-canvas implementation if you detect that the user is using an IE User Agent string, you may be blocking HTML5 content from rendering in IE9. Instead of doing browser detection, you should do feature detection to check if the user’s browser has a certain capability. For instance, you can use this code to check if your user’s browser supports canvas:
var canvas = document.createElement("canvas");if (canvas.getContext && canvas.getContext("2d")) {
{ // Code requiring canvas support} else { // Canvas isn't available. Put non-canvas fallback here}This eliminates the need for you to make assumptions about current browser feature support and ensures your site will continue to work as browsers evolve. We explain more about feature detection in this post.
How to check if the user’s browser supports Canvas:
Make sure your site is in IE9 mode
By default, if your site is following web standards, such as using a standards DOCTYPE, IE9 will render it in standards mode. You can check if your site is in this mode by bringing up the Developer Tools (press F12) and checking to see if your site is in IE9 standards Document Mode.
Canvas is a new feature only supported in IE9 standards mode – a design decision we took to ensure that legacy document modes remain fully backward compatible. If you see a Document Mode for your site other than IE9 standards, HTML5 elements like canvas won’t be displayed. For example, if you don’t have a DOCTYPE in your page, IE9 will display the site in Quirks Mode. To ensure your page works as expected in IE9, we recommend that you add a strict DOCTYPE to your webpages. For example, you could add the W3C HTML5 DOCTYPE:
<!DOCTYPE html>
Or you can use a common strict DOCTYPE such as this:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
You can read more about how IE determines the document mode here.
Interoperability and Canvas
Interoperability is a high priority for IE9, to the point where we recommend sending IE9 the same standards-based markup your site sends to other browsers. Most canvas sites should just work on IE9 if the site was originally developed for another browser. That being said, there are a few behavior differences between browsers. For instance, consider the shadow demo from the Canvas Pad test drive site.
This is one example of a canvas feature that is rendered a little differently in each browser. We are making IE9 interoperable whenever possible, but for some canvas features, other browsers do not have a complete or correct implementation. In these cases, we follow the W3C spec. We submit test cases to the W3C as a way to help ensure everyone agrees on how the spec should be interpreted and implemented. To learn more about our shadow implementation, check out our canvas tests from the IE Test Center.
The purpose of the W3C spec is to define a standard that all browsers should follow. If we find examples where browsers uniformly behave differently from the spec, we feel that spec should be updated to reflect the interoperable behavior, if it makes sense for web developers. For instance, HTMLFrameElement did not contain the contentWindow attribute in the W3C spec; however IE8, Firefox, and Chrome all support this attribute. We filed a bug with a proposed change, and the HTML5 editor updated the latest revision of the spec.
If something looks unexpected in IE9 and you believe it is an interoperability issue or an area where we deviate from the spec, please let us know by filing a bug with Microsoft Connect. One of our goals around the platform previews and the beta of IE9 is to give our users a chance to give us as much feedback as possible, so don’t hesitate to let us know if you think you see a bug!
Thanks,
Elizabeth Ford and Jatinder Mann
Program Managers, Internet Explorer
Edit 9/9: Updated the detection code sample to be more robust. Thanks to Paul Irish for pointing out this problem.
September 8th, 2010
The Web Applications Working Group has published a Last Call Working Draft of Document Object Model (DOM) Level 3 Events Specification. DOM Events is designed with two main goals. The first goal is the design of an event system which…
September 8th, 2010
Hi! In this build, we present to you a new Mail panel with more functionality. And there is more, so read on below.
The Mail Panel
With this new Mail panel, you can decide for yourself what items to show, and in what order. Not using the ‘Attachments’? Just hide it. Want your IMAP account on top? Just drag it up. Etc. Furthermore, you can now create folders to organize your mailing list and newsfeeds, which is great for users who have many of them. It is also possible to select in each category (like Attachments, Labels, Feeds, etc) which individual items to show and which items to hide.
Speaking about feeds, you now will get the Mail panel for easy switching between feeds, without having to set up any mail accounts. As long as you don’t set up a mail account, the panel will only contain your feeds with a dedicated toolbar and context menu :wizard:
Other changes are the automatic appearance of the Mail panel whenever you switch to a mail tab – and automatically returning to the previous state of the panels when moving back to a not-mail tab. Also, POP accounts have gained Inbox and Sent views for themselves.
This is phase one of the mail panel work. Phase two is now being worked on, and will see a better UI for Filters/Labels/Searches, support for feed folders in OPML import/export, a nicer look especially for Mac, and a better way to deal with multiple mail accounts (which can currently take up a lot of vertical space). So stay tuned, and tell us what you think of phase one!
More news
Known regressions
WARNING: This is a development snapshot: It contains the latest changes, but may also have severe known issues, including crashes and data loss situations. In fact, it may not work at all.
Download
Note: If you are looking for a PowerPC build, please see our earlier blog post. …
September 8th, 2010
Andreas has made significant contributions to the Qt port of WebKit for the past year, and has lately been focusing his efforts on the 2D canvas, optimizing Qt rendering performance, and DOM compliance.
Please join me in congratulating Andreas on his reviewer status!
September 8th, 2010
In my recent blog post, Chakra: Interoperability Means More Than Just Standards, I explained why IE9 only supports the ECMAScript 5 API for defining getter/setter methods. I also mentioned that it is fairly trivial to define a simple compatibility library to help transition existing code to this new API. This is part of what it means to support the same markup using feature detection, not browser detection, so you get the same results in different browsers. In this post I‘ll show you the code for such a library.
Using the non-standardized legacy getter/setter API supported by some browsers you normally define a getter/setter property in a manner such as this:
myObject.__defineGetter__("p", function() {/* getter function body */});myObject.__defineSetter__("p", function(v) {/* setter function body */});Using the standard ES5 API, the equivalent definitions look like this:
Object.defineProperty(myObject,"p", {get: function() {/* getter function body */}});Object.defineProperty(myObject,"p", {set: function(v) {/* setter function body */}});As you can see, each __defineGetter__ or __defineSetter__ method call is mapped to an equivalent call to the ES5 Object.defineProperty function. If you have existing code that contains many such calls that you need to work in IE9 or any other ES5 complaint browser, you can avoid a lot of editing and automate this mapping process. You can do this by creating definitions of __defineGetter__ and __defineSetter__ that use defineProperty to create the getter/setter properties and include these definitions in your code. Here is what you need:
//emulate legacy getter/setter API using ES5 APIstry { if (!Object.prototype.__defineGetter__ && Object.defineProperty({},"x",{get: function(){return true}}).x) { Object.defineProperty(Object.prototype, "__defineGetter__", {enumerable: false, configurable: true, value: function(name,func) {Object.defineProperty(this,name, {get:func,enumerable: true,configurable: true}); }}); Object.defineProperty(Object.prototype, "__defineSetter__", {enumerable: false, configurable: true, value: function(name,func) {Object.defineProperty(this,name, {set:func,enumerable: true,configurable: true}); }}); }} catch(defPropException) {/*Do nothing if an exception occurs*/};The if statement does feature detection to determine if the compatibility definitions are necessary. There are two parts to this determination. First it checks whether __defineGetter__ is already available. If it isn’t, it then checks that defineProperty is available and that it supports creating getter properties. It does this by trying to use defineProperty to actually define a getter property named x for a new object and then trying to access that property. If defineProperty isn’t available the attempt to call it will raise an exception which is caught by the try-catch statement that surrounds the if statement. If defineProperty is available but it does support the creation of getter/setter properties on normal objects the call will either throw an exception or the access to the value of x will return undefined, which is a false value. This testing of both the existence and operation of defineProperty is necessary because IE8 includes defineProperty but only supports its use with DOM objects. This is an example of a situation that illustrates that browser feature detection sometimes needs to carefully probe for the desired functionality. Simple checking for the existence of an object or method is not always sufficient.
If these conditions are met then it is possible to emulate the legacy API. The two calls to defineProperty in the body of the if define the actual legacy API methods. The bodies of these methods, when called also use defineProperty to create getter or setter properties.
This code should be inserted at the beginning of an application before any calls to __defineGetter__ or __defineSetter__ are made. In practice, you may want to insert this code into a separate script file that you load before any other code.
With this compatibility code included, your application that uses __defineGetter__ or __defineSetter__ should work on any browser that supports getter/setter properties. If a browser only supports the new ES5 API, the compatibility methods are automatically defined and used. If a browser only supports the legacy API or if it supports both the legacy and ES5 APIs the compatibility methods are not necessary, and the built-in versions of __defineGetter__ or __defineSetter__ are used.
What if you are writing new code that needs to define getter/setter properties? You probably will want that code to run in both new ES5-based browsers and in older browsers that only support the legacy API? You could use this same compatibility package and use the legacy API to define the getter/setter properties. However, it is more forward compatible to write new code using the standard ES5 APIs. You can do this by creating a different compatibility package that uses the legacy API to emulate the ES5 API. Here is the code:
//emulate ES5 getter/setter API using legacy APIsif (Object.prototype.__defineGetter__&&!Object.defineProperty) { Object.defineProperty=function(obj,prop,desc) { if ("get" in desc) obj.__defineGetter__(prop,desc.get); if ("set" in desc) obj.__defineSetter__(prop,desc.set); }}The if statement is again a feature detection check. This time it makes sure that the old API is present and that the ES5 API is missing. If this is the case, it defines the Object.defineProperty function to detect any uses that are trying to define either a getter or a setter or both and then uses the legacy API to actually define them. Note that this is only a partial implementation of the defineProperty functionality. ES5’s defineProperty function can be used to perform other forms of property definition or redefinition in addition to defining getter/setter properties. Many of these new capabilities cannot be easily emulated using common legacy APIs so this compatibility version of the function does not attempt to do so. It just supports getter/setter property definitions.
We all want more capable browsers that enable more compelling web sites. Sometimes new browser functionality introduces dilemmas for web developers who want the same markup to produce the same results across browsers. Developers may ask; do you use the new functionality with the result that your application will not work on older browsers, or do you simply ignore the new functionality? Simple compatibility packages like the ones described here are a pragmatic way to deal with these situations and get the best of both worlds.
Allen Wirfs-Brock
Microsoft JavaScript Language Architect
Edit 9/7 – fixed type in third paragraph
September 8th, 2010
James has been working on bug fixes and performance improvements in the layout and rendering parts of WebKit, as well as working on the Chromium port. Recently, he has been adding support for hardware accelerated rendering. He has already given solid feedback in informal code reviews for areas in his expertise, and I look [...]
September 7th, 2010
The latest update to Firefox 4 Beta brings super fast graphics and incredible new audio capabilities to the Web. Firefox 4 Beta now leverages hardware acceleration to improve graphics performance for Windows users and also allows, for the first time, the visualization of audio data within the browser. If you haven’t already, you should download [...]
