Development is slowly getting back on track with the 851 commits which were done last week. This week’s highlights include the availability of a per element JavaScript full screen API, a prefixless Navigation Timing implementation and the addition of support for repeating CSS gradients.

With both Microsoft and Google strongly pushing the Navigation Timing specification, both vendors finished most of their implementation and a Last Call specification will be published tomorrow. Because of this, WebKit has dropped the vendor prefix and Microsoft is very likely to do the same. Opera and Mozilla have expressed concerns, but seem supportive as well. It’ll certainly become an interesting Last Call phase.

As for other specification-related changes, text emphasis marks won’t appear over characters that have ruby annotations anymore. Support for repeating gradients has been added as well, completing the set of gradient related CSS properties. Negated selectors will be given the specificity of the selector they’re negating, and parsing of the argument for the :nth-child CSS selector has been updated and now accepts whitespace, but rejects invalid values.

...
var elem = document.getElementById("my-element");
elem.onwebkitfullscreenchange = function () {
console.log ("We went fullscreen!");
};
elem.webkitRequestFullScreen ();
..

After several months of writing and updating patches, Jer Noble landed the final part of his work on supporting per-element full screen last Friday. While the implementation is only available in WebKit nightlies on Mac OS systems so far, I’d expect a Windows nightly rather soon and Chromium is interested as well.

WebKit’s implementation follows Mozilla’s proposal with only a few exceptions: instead of accepting flags for requestFullScreen, an additional method called requestFullScreenWithKeys has been made available. The following three methods have been added for the Document and all Elements in the DOM:

void webkitRequestFullScreen();
void webkitRequestFullScreenWithKeys();
void webkitCancelFullScreen(); // only on Document

Furthermore, a new attribute called allowFullScreen has been introduced for iframe elements, the fullScreenChange event has been added and three CSS pseudo-classes have been added, namely :full-screen, :full-screen-doc and :full-screen-root-with-target. Mind that each of these additions has been prefixed with “webkit” or “-webkit-“, depending on the context.

Want to try the feature yourself?
All you need is a Mac OS X system on which you can run WebKit nightlies. Download and install the latest one and open up Terminal. Within it, execute the following command to enable the feature:

defaults write com.apple.Safari WebKitFullScreenEnabled 1

After (re)starting the nightly, the exposed API will actually launch an element in full screen. Click on the icon to the left of this paragraph to display this very article in full screen. Using it to display a single element in full screen can be done too, but still is a bit unstable at the time of writing.

Other changes which occurred last week:

• The disabled property on stylesheet elements will now disable the sheet altogether.
• Adam Barth moved the WebCore directory, containing most of WebKit’s code, to Source.
• A memory sampler has been added to WebKit, primarily for usage in Safari on Mac OS X.
• The onbeforeunload event is now available for framesets as well.
• SGML-style comments within <style> elements will now be ignored when using XHTML.
• Tabbed options (also known as WebUI) have been enabled by default in Chromium.
• Per an update in the HTML5 specification, framesets will now be allowed after hidden inputs.
• The Web Audio API received some more work for the Chromium port.
• Mihai Parparita now is a WebKit reviewer, congratulations!
• The PNG compression settings for Chromium have been optimized for performance.
• Inline script execution will now block on pending stylesheet loads, as other browsers do.
• The O3D Plugin API will now work with Opera 11 as well.
• Web Inspector has been enabled for all internal chrome:// pages.
• The icon for active background extensions over the wrench menu in Chrome has been updated.
• The position of Notifications can now be changed via a notification’s option menu.

This week might bring four times faster JavaScript to Samsung’s EFL port, support for the object-fit CSS property and, hopefully, much more patches from the Web Inspector team. Have a good week!

Read more (19 comments) »

Today, exactly 217 days after the first Internet Explorer 9 announcement, Microsoft has released the third Developer Preview of the latest version of their browser. One of the most awaited and unannounced features this preview brings is the addition of the HTML5 Canvas Element. Defined in section 4.8.11 of the HTML5 specification, already implemented in all other major browsers, and now upcoming for Microsoft’s Internet Explorer 9: 2D Canvas is a go!

The history of <canvas>

The first signs of the -then still proprietary- element were committed to the WebKit source tree by Richard Williamson on the 25th of May, 2004. Apple’s idea came down to exposing Mac OS X’s Quartz drawing system to JavaScript and HTML in order to ease up writing graphical widgets for the Apple Dashboard. Consequently, as both products share the rendering engine, the element became available in the Safari browser as well.

In July of that year Dave Hyatt announced the new element on the Surfin’ Safari blog. This immediately brought up a lot of controversy, of which Eric Meyer’s post is a clear example: “What the bleeding hell?!?” In defense, Hyatt elaborates Apple’s rationales for including the proprietary features and said to submit a proposal to the WHATWG lists, however, it never came. Ian Hickson therefore, despite his opinion on how Apple handled the new elements, reverse engineered a draft based on available source code.

A few years earlier, late October 2001, Joe Hewitt opened bug 102285 in Mozilla’s bug tracker. Sharing the same name and rationale, his proposal was to implement a custom painting control to Mozilla’s XML User Interface Language. Interestingly enough, Brendan Eich, founder of the JavaScript language, tore down the idea as something for rendering fanboys. The patches were never used, and inclusion in official builds was unlikely, as Eric Murphy stated in the discussion.

On the first day of April in 2005 Mozilla’s Vladimir Vukicevic uploaded a patch featuring basic canvas functionalities, which opened the road for further work in Firefox. While this first implementation only worked on Linux due to different color formats on Windows and Mac OS X, the release of their “Deer Park” project late November, known as Firefox 1.5, featured a cross-platform implementation of canvas.

Opera introduced the <canvas> element mid 2006 with their Opera 9 release, in quite a humble way (can you see it without searching?). This meant that all major browsers, with the exception of Internet Explorer, implemented the element natively. However, it didn’t mean that the element was unusable, as Google’s ExCanvas and Mozilla’s IECanvas projects brought limited support for the element to Microsoft’s browser.

The long and juridical path to standardization

The path to proper standardization wasn’t very smooth. This began with the lack of a proper proposal coming from Apple’s side, resulting in the initial specification being based on reverse engineering works by Ian “Hixie” Hickson, editor of the HTML5 specification. In 2005, Jayant Sai brought up an initial idea for drawing text on a canvas, which later got formalized into a decent proposal by Stefan Haustein.

However, not everything went nice and smooth. After Mozilla Firefox and Opera had implemented the element, Apple’s Senior Patent Counsel Helene Plotka Workman sent a message to the WHATWG and Ian Hickson stating that Apple believed to have intellectual property over the canvas element, and would only consider to release these IP Rights if the Web Applications draft would become a formalized draft standard with the W3C.

Despite the fact that the rationale behind Apple’s message was unclear, the timing of their message was interesting. Exactly a week before, the W3C would be re-launching the HTML Working Group. Less than half a year later, in February 2008, the first draft of the HTML5 specification was published as a W3C Working Draft. On the 18th of June that year, Apple disclosed patent 11/144384 for use by the HTML5 specification. The same patent has been disclosed in six other jurisdictions, enabling the WHATWG to continue including <canvas>.

Going 3-dimensional with WebGL

More recently, on December 10 last year, Mozilla’s Arun Ranganathan announced the first draft of the WebGL specification. While you would expect the specification to be hosted by either the WHATWG or the W3C, because it defines a context for the HTML5 Canvas Element, WebGL is available at Khronos. This can be explained by the fact that the specification originally was intended as a simple binding of OpenGL ES2.0 to JavaScript, whereas the Khronos consortium already hosted the OpenGL ES specs.

WebGL is the second context that can be used with the <canvas> element. As said before, it has been based on the OpenGL ES 2.0 specification and provides a JavaScript interface for 3D graphics. The specification has evolved out of an experiment by Mozilla’s Mozilla’s Vladimir Vukicevic. He first demoed the possibilities in his “Web Graphics: Canvas, SVG, and more” talk at XTech 2006, and later announced as the “moz-glweb20? context. Opera published their opera-3d context late 2007, but decided to add abstraction in order to leave the door open for other implementations based on, for example, Direct3D.

WebGL is a specification in which all browser vendors, with the exception of Microsoft, participated. This can be clearly seen by the fact that nightly builds of Firefox, Google Chrome and Safari contained implementations of WebGL. While Opera actively participated in discussions, they have yet to release a public build containing the 3D context. Nokia has announced WebGL support in a new firmware version for their Nokia N900 phone.

Of course, Google hasn’t been silent either. In May they announced the ANGLE project, which basically translated OpenGL calls to their DirectX equivalents. Two weeks later, on April Fools’ this year, Googler Chris Ramsdale announced a WebGL port of the Quake II Game Engine.

No really, Thank You, Microsoft!

Even before the Internet Explorer 9 announcement, Microsoft tried to move the Canvas 2D context to its own module. There was no word about <canvas> in the first two Developer Previews, and the company’s position could best be described as vague. In May, Microsoft Evangelist Giorgio Sardo publically stated that he would like the element to be included, but also added that the company was in no way committed to Canvas.

More recently, at the SVG Working Group meeting earlier this month, Internet Explorer’s General Manager Dean Hachamovitch stated that the team wouldn’t be talking about implementing Canvas at that point. However, he added the following: “all your graphics needs will be taken care of, and I’m smiling broadly.” Today they finally confirmed the suspicion a lot of web developers have been having for months: the 2D canvas has been included in Internet Explorer 9.

Thank you, Microsoft, you’ve just made us smile broadly as well.

Read more (7 comments) »

One of the subjects Microsoft is giving a lot of attention to in Internet Explorer 9 is graphics: extensive SVG implementation plans, various CSS specifications related to graphics, and with GPU Acceleration available by default. This isn’t entirely surprising: considering Microsoft owns the operating system and graphic libraries which have to be used for the acceleration and only support a limited amount of configurations, implementation is a lot easier than having to create cross-platform implementations based on third-party software.

Nevertheless, they are doing quite a good job at implementing the specifications, and certainly with a lot of sense for the finer details. A good example of this can be found in their rendering of borders. One of the new CSS properties that Internet Explorer 9 introduces is border-radius, as defined in the Backgrounds and Borders specification. While the specification still isn’t entirely clear on how to render mixed border-style connections, Microsoft’s latest implementation does look smooth and well adapting.

Scalable Vector Graphics

SVG is becoming a widely implemented specification for scalable graphics. With a file format based on XML, confirmed support for in-line HTML rendering in three major browsers, a mature specification and lots of support from professional graphic editing software such as Adobe Illustrator, it’s destined to strongly gain in popularity in the near future.

Internet Explorer 9 will support the entire SVG 1.1 specification, with the exception of Fonts, Filters and SMIL. Microsoft believes that web fonts have a decent future as it is, mainly because the W3C Fonts group is making vast progress in standardizing a common format. Filters will not be included because they are not convinced about how often they will be used, considering Internet Explorer has supported various filters since version 4, but barely anyone has used them. Finally, SMIL will be omitted because the company believes there would be too many different ways of handling animation. A fair reason, as CSS 3 introduces two additional ways of adding animation to your webpage.

Per-pixel rendering using <canvas>

While the Internet Explorer team is making a lot of progress with the development of Internet Explorer 9, not only on the technical side, but also through a development process which is more open than was the case with previous releases, their position on the HTML5 canvas element is simply vague. Early May Giorgio Sardo, an Internet Explorer evangelist, already indicated that he would like to have support for the element in IE9, but the company has neither confirmed nor denied inclusion of the element in the new browser. Just yesterday, however, Dean Hachamovitch hinted that Microsoft still has some tricks up their sleeve: “We’re not talking at this point about whether we’re supporting canvas or not, but I’m smiling broadly. All your graphics needs will be taken care of, and I’m smiling broadly.”

My guess would be, something I have been saying ever since the release of the first Internet Explorer 9 Platform Preview, that they certainly will be implementing canvas. I mostly base this on their attention to the graphical aspects of IE9, as well as on the comments made by various Microsoft employees. As Mozilla’s Brendan Eich already said about the subject: “Canvas is pretty small. It’s like your postscript level to 2D graphics.” I’m assuming that Microsoft knows their own APIs by heart, so implementation of the 2D canvas standard shouldn’t be a problem at all. In fact, utilizing the power of the Direct3D API, I’d say even WebGL is a likeliness. Microsoft is smiling broadly, let’s hope they allow us to do the same.

Read more (2 comments) »