Blog
July 7th, 2009
One of the biggest wins of the HTML 5 recommendation is a detailed specification outlining how parsing of HTML documents should work. For too many years browsers have simply tried to guess and copy what others were doing in hopes that their parser would work well enough to not cause too many problems with HTML markup found in the wild.
While some parts of HTML 5 are certainly more contentious than others - the parsing section is one that is almost universally appreciated by browser vendors. Once browsers start to implement it users will enjoy the improved compatibility, as well.
One of the first implementations of the HTML 5 parsing rules was actually created to power the HTML 5 validator. (If you're interested in testing it out, http://ejohn.org/ should validate as HTML 5.) This particular implementation is in Java, provides SAX and DOM interfaces for use, and is open source.
This is particularly interesting because Henri Sivonen (the author of the validator) just recently landed (Warning: Massive web page) a brand new HTML 5 parsing engine in Gecko, destined for the next version of Firefox.
What's interesting about this particular implementation is that it's actually an automated conversion of Henri's Java HTML 5 parser to C++. This conversion happens automatically and changes will be pushed upstream to the Mozilla codebase.
Normally I would balk at the mention of a wholesale, programmatic, conversion of a Java codebase over to C++ but the results have been very surprising: A 3% boost in pageload performance.
And this is on top of the litany of bug fixes and compliance checks that this code base will be providing. You can examine some of the progress that went into the constructing the patch in the Mozilla bug.
If you're interested in giving the new parser a try (it's doubtful that you'll see many obvious changes - but any help in hunting down bugs would be appreciated) you can download a nightly of Firefox, open about:config, and set html5.enable to true.
If there was ever a time to start playing around with the jump to HTML 5, now would be it. Since HTML 5 is a superset of the features provided by HTML 4 and XHTML 1 it ends up being surprisingly easy to 'upgrade': Just start by swapping out your current (X)HTML Doctype for the HTML 5 Doctype:
<!DOCTYPE html>
From there you can check the site HTML 5 Doctor for additional details on how to get the new HTML 5 elements working in all browsers.
Tags: mozilla, firefox, html5
13 Comments on 'HTML 5 Parsing'
December 18th, 2008
In my work with the Firebug team over the past couple months I've been working with Jan Odvarko on a way to provide some form of unit testing that we can build off of. The result of my work is a new Firefox/Firebug extension called FireUnit.
FireUnit provides a simple JavaScript API for doing simple test logging and viewing within a new tab of Firebug.
For example, here's some of the API that you can use (we're starting with the basics and looking to expand with more methods, later).
// Simple true-like/false-like testing
fireunit.
ok( true,
"I'm going to pass!" );
fireunit.
ok( false,
"I'm going to fail!" );
// Compare two strings - shows a diff of the
// results if they're different
fireunit.compare(
"The lazy fox jumped over the log.",
"The lazy brown fox jumped the log.",
"Are these two strings the same?"
);
// Compare a string using a regular expression
fireunit.reCompare(
/The .* fox jumped the log./,
"The lazy brown fox jumped the log.",
"Compare a string using a RegExp."
);
// Display the total results
fireunit.testDone();
The results will appear in a 'Test' tab in Firebug (which must be installed in order for Fireunit to work). Each of the results can be expanded to show additional information including a full stack trace of where the test ran and a comparison with a diff.
FireUnit also provides a couple methods for simulating native browser events:
// You can also simulate browser events
var input = document.getElementsByTagName("input")[0];
fireunit.mouseDown( input );
fireunit.click( input );
fireunit.focus( input );
fireunit.key( input, "a" );
And a way of running a batch of test files (each of which would contain a number of individual tests).
// Or run multiple pages of tests:
fireunit.
runTests("test2.html",
"test3.html");
// Place at the end of every test file in order to continue
fireunit.testDone();
We've been using this test runner to run a number of Firebug tests, especially ones that are network based.
Depending on the suite it's pretty easy to adapt existing test suites to display their results in FireUnit.
Running the jQuery selector test suite that has the following snippet added:
if ( typeof fireunit === "object" ) {
QUnit.log = fireunit.ok;
QUnit.done = fireunit.testDone;
}
Yields the following results (which are completely navigable):
If you want to get started using FireUnit you can head on over to the Fireunit.org site and download the latest extension.
You can also grab the source off of the repository on Github.
Jan has also written a blog post detailing a little bit more about what we're using FireUnit for in the Firebug Working Group.
This is still a very early release of our work - there's obviously a ton of room left to grow - so feedback is expected and appreciated.
Tags: extension, firefox, firebug, javascript, testing
44 Comments on 'FireUnit: JavaScript Unit Testing Extension'
October 13th, 2008
A cool new browser event just recently landed in the latest Firefox nightlies: an event announcing when the browser re-draws a portion of the page.
This particular event, called MozAfterPaint fires whenever something is drawn to the screen.
The event object contains two properties: .clientRects and .boundingClientRect, both of which refer to the result of the associated DOM methods.
In a nutshell, boundingClientRect gives you a single rectangle encompassing the entire area in which a paint operation could've taken place whereas clientRects gives you a number of rectangles, each encompassing an individual area that was drawn.
To test this I created a quick demo using CNN.com (only works in the latest Firefox nightlies).
To use the demo let the page load then move your mouse around (triggering new paint events). When you're done simply click anywhere on the page to draw the overlay.
You can use the tracking script on any page, simply copy this bookmarklet to your toolbar in a Firefox 3.1 nightly: Track Paint. Then activate it on a page where you wish to track paint events. (Clicking anywhere on the page will show the results.)
For example I ran the bookmarklet on the jQuery.com homepage, moved my mouse over the navigation, hovered over the tooltips, and finally focused on the checkboxes before clicking - creating this complete visual effect:
The important part of the tracking code is as follows:
function log
(e
){
store.
push( e.
clientRects );
}
// To start logging...
window.addEventListener("MozAfterPaint", log, false);
// After logging is done...
window.removeEventListener("MozAfterPaint", log, false);
You have to be sure to do all of your logging in a separate part of the application (don't do any rendering inside the MozAfterPaint event handler, otherwise you'll cause some recursion to occur). Thus before you render the results the MozAfterPaint handler should be removed from the page.
It's likely that the primary use of this event will be within extensions (such as Firebug) mostly due to the fact that the overhead incurred by initiating this event is so high.
Nonetheless I think this addition to the browser is absolutely fantastic. Developers have been craving more information about what's going on underneath the hood and this is starting to provide exactly that.
Tags: firefox, browsers
13 Comments on 'Browser Paint Events'
August 22nd, 2008
I've been waiting to blog about this for a long time now. A fantastic new improvement to Mozilla's JavaScript engine (SpiderMonkey) has landed. Code-named TraceMonkey this engine utilizes a techniques, called trace trees (PDF), which adds just-in-time native code compilation to SpiderMonkey.
A major goal of the project has been to set JavaScript up to compete with natively-compiled code, rather than simply against other interpreters. This means that we're starting to see speeds that are completely out of this league when it comes to performance.
Results and Try it Yourself
Here are the results from four benchmarks to give you a taste:
(Graph courtesy of Brendan Eich.)
The tests are:
If you want to try these out for yourself, just snag a nightly of Firefox 3.1, open about:config, and set the following preference to true:
javascript.options.jit.content
You should be, happily, in just-in-time tracing land. It's still buggy (hence the reason for hiding behind the preference wall) but it should be good enough to handle most web sites.
What's especially exciting is that this code is working on x86, x86-64, and ARM - which means that these improvements won't be limited to just the desktop - you'll be able to receive them on your mobile devices as well.
How Tracing Works
In simple terms tracing works by watching for commonly-repeated actions (such as loops, function calls, or type checking) and tries to optimize their resulting native code into the lowest number of actions. The premise is rather simple - and it's an advance that we'll probably see proliferate to many interpreters and engines in the upcoming years.
Andreas Gal published a paper (PDF) on the subject and Brendan Eich has written up a TraceMonkey-specific explanation.
Some of the improvements made by tracing include:
- Function Inlining: Removing the overhead of function calls by simply replacing them with their resulting native code.
- Type Inference: Removing checks surrounding common operators (like "+") when the types contained within a variable are already known. This means that the engine will have already pre-determined, for example, that two strings need to be concated when it sees the "+" operator.
- Looping: The overhead of looping has been grossly diminished. It's one of the most common areas of overhead in JavaScript applications (common repetition of a task) and the constant determining of bounds and the resulting inner code is made negligible.
The code for this project has come from a number of places - one of which is coming from some code contributed to Mozilla, from Adobe: Tamarin Tracing, specifically the nanojit code that's able to work a lot of this just-in-time magic.
Development
The work began just about 60 days ago, working with Andreas Gal of UC Irvine, to integrate the nanojit technology into Spidermonkey. You can hear more about the development from those that were involved: Andreas Gal, Mike Shaver, and Brendan Eich.
The full code can be found in the TraceMonkey mercurial repository (the commit to merge TraceMonkey into Mozilla core is massive, clocking in at about 4MB).
If you want to try running your own copy of TraceMonkey on the command-line, just follow the steps outlined here.
There is still a ton of work to be done. The incredible speed-ups that we're seeing are only just the beginning. A lot can be done to improve how registers are currently being allocated which will provide even more speed-ups.
Right now there isn't any tracing being done into DOM methods (only across pure-JavaScript objects) - but that is something that will be rectified. Being able to trace through a DOM method would successfully speed up, not only, math and object-intensive applications (as it does now) but also regular DOM manipulation and property access.
Ramification
So what does this all mean? It means that JavaScript is no longer confined by the previously-challenging resource of processing power. With this improvement it's leap-frogged any sort of traditional and has gone head-to-head with computationally-powerful languages like C.
I fully expect to see more, massive, projects being written in JavaScript. Projects that expect the performance gains that we're starting to see. Applications that are number-heavy (like image manipulation) or object-heavy (like relational object structures).
One area that I'm especially excited about is in relation to Canvas. The primary thing holding back most extensive Canvas development hasn't been rendering - but the processor limitations of the language (performing the challenging mathematical operations related to vectors, matrices, or collision detection). I expect this area to absolutely explode after the release of Firefox 3.1 as we start to see this work take hold.
Seeing releases like this are absolutely exciting for me. JavaScript is absolutely the little-language-that-could - continually routing around any of its short-comings and blowing away all of its expectations. I look forward to using it for many, many, years to come.
Tags: tracemonkey, mozilla, firefox, javascript
77 Comments on 'TraceMonkey'
August 20th, 2008
A brand-new implementation of the Selectors API has landed in the latest Firefox nightlies (and in Firefox 3.1a1) - on track to head your way in the upcoming Firefox 3.1 release.
I've talked about this API before (1, 2) and while I do have some misgivings about the current API (which will be remedied in upcoming revisions of the spec) there is one thing that is undeniable about it: It is extraordinarily fast.
Thankfully, implementations haven't scarified specification compatibility for performance and we can see both the Firefox and WebKit implementations coming in at 99.3% passing the Selectors API test suite. Opera is working on their implementations, slated for Opera 10, and Microsoft has an implementation in beta 1 of Internet Explorer 8. This means that by late this year all browsers will have an implementation of the Selectors API in the market.
JavaScript libraries have already been working to utilize this new API, preparing for when it'll eventually be ready for all to use. The current score is:
- Dojo has querySelectorAll support in Dojo 1.1.1, although support for Safari 3.1 is disabled (there were troublesome crashing bugs in early versions of Safari 3.1 that have since been resolved).
- Prototype has querySelectorAll support in their Git repository (presumably to be rolled into their next release).
- jQuery has querySelectorAll support in an experimental plugin (to land in the next release).
This has lead to some interesting numbers (utilizing the same testing techniques employed by the WebKit team):
| Library |
Time (ms) |
| Prototype 1.6.0.2 |
44677 |
| Prototype Git |
9914 (123% slower than native, 351% faster than DOM) |
| jQuery 1.2.6 |
35045 |
| jQuery 1.2.7 Plugin |
4731 (7% slower than native, 641% faster than DOM) |
| Dojo 1.0.2 |
20782 |
| Dojo 1.1.1 |
5669 (28% slower than native, 267% faster than DOM) |
| Native |
4441 |
That means that libraries that utilize querySelectorAll will be running 2-6x faster than their previous versions. This is already quite impressive.
There are two points to consider when using this API:
- That you need to try and keep the overhead on top of the querySelectorAll method as low as possible.
- That it becomes advantageous to avoid the querySelectorAll API in some extreme cases (for example, jQuery avoids it for #id queries, allowing it to go over 10x faster than querySelectorAll).
A lot of bare-bones selectors library implementations are going to look something like this:
function querySelectorAll(selector){
try {
return Array.prototype.slice.call(
document.querySelectorAll( selector ) );
} catch(e){}
return myOtherLibrary( selector );
}
Note two points: There's a try-catch block there to capture any syntax errors that are generated by querySelectorAll (syntax errors could be generated by APIs that the implementation doesn't understand - like jQuery's div:first, for example). If no exception is thrown while retrieving the results we need to convert it into an array (most libraries convert result sets into arrays - or bless them in some manner).
Tackling both of these points will introduce some level of overhead in a library (on top of the native querySelectorAll implementation). Of course it's never as simple as it should be, many libraries extend these return sets with additional functionality so the overhead will be that much greater.
Regardless it's readily apparent that this API will be quite instrumental in trivializing one of the most difficult parts of implementing a new JavaScript library. Everything after this is just gravy.
Tags: mozilla, javascript, jquery, selectors, firefox
20 Comments on 'querySelectorAll in Firefox 3.1'
August 13th, 2008
For the upcoming Firefox 3.1 release a lot of work has been going into improving its CSS support (specifically, in relation to the CSS 3 specification).
One areas that have received solid implementations is that of border-image. This is a new CSS 3 module that makes the exact slicing of images (and their positioning around an element) quite easy.
The most obvious use case for them exists in constructing beautiful scalable buttons. And there is, perhaps, no better use case than the one provided by the iui library: replicating portions of the iPhone user interface in a pure-CSS manner.
Here are two examples from the iui library (slightly tweaked to support both WebKit's and Mozilla's implementations of border-image).
You will need a nightly release of Firefox in order to have the following demos work properly.
The button on the top right ("Search") is mostly implemented using the following CSS:
border-width: 0 5 0 5;
-webkit-border-image: url(toolButton.png) 0 5 0 5 stretch stretch;
-moz-border-image: url(toolButton.png) 0 5 0 5 stretch stretch;
With toolButton.png looking like:
The premise behind border-image is complex, but easy to learn. When used in the manner shown above you are, effectively, providing slice offsets into the provided image - telling the browser how to position the slices.
For example the 5s in the border-width and border-image indicate that there should be a 5px-wide border on the left and right of the button. The contents of the border should be populated with the left and right-most 5 pixels from toolButton.png. Since a horizontal border width value is provided it is possible to scale the contents of the button horizontally (inserting more contents will allow it to continue to work properly).
The 0s, on the other hand, indicate that entirety of the button background should be consumed by toolButton.png - and that none of it should be used to show the border (border-image can be used as a crude mechanism for injecting background images). Because of this the image won't be able to gracefully scale vertically.
CSS3.info provides another example that shows how the stretching and rounding work.
with the following base image:
Rounding:
Stretching:
By tweaking the stretching of the border-image you can end up with some truly-compelling results.
We can see another one in a second iui button:
With the following CSS being used:
-webkit-border-image: url(whiteButton.png) 0 12 0 12 stretch stretch;
-moz-border-image: url(whiteButton.png) 0 12 0 12 stretch stretch;
together with this base image:
border-image has a large number of compelling use cases. It's fantastic to see some coordinated efforts by browser vendors to make their implementations common-place.
Tags: mozilla, css3, css, firefox
21 Comments on 'border-image in Firefox'
July 17th, 2008
I've got a mini-announcement. Starting this week about half of my time at Mozilla is going to be spent driving the direction of the brand-new Mozilla Firebug team. I'm, understandably, quite excited about this proposition. Like all web developers I've found Firebug to be an invaluable tool for web development.
We have a great team forming - I'm going to be joined by:
We're in a very primordial stage right now - we're meeting at the Firefox Summit at the end of the month and again at the beginning of August for the Firebug Working Group. We'll be setting some major goals for post-Firebug 1.2 development. I highly suspect that we'll be doing some exploratory Firebug extension development as well.
In the meantime we'll be hanging out in the Firebug IRC channel, which can be found here:
Server: irc.mozilla.org
Room: #firebug
We're going to love to hear any suggestions for feature development - I'm sure you've got tons of ideas - and we do as well. I'm quite excited about all of this. Here's to a bright Firebug future!
Tags: firebug, firefox, mozilla
75 Comments on 'Firebuggin''
July 10th, 2008
This week I've been busy working on implementing a test suite for the Selectors API specification. I picked up a new microphone recently so I decided to do a quick walkthrough of the work that I've been doing and how I've been going about it. You can view the the video below:
Implementing a Selectors API Test Suite
You can run the test suite for yourself here (it's still very much in flux - there are various parts that may still be wrong):
http://ejohn.org/apps/selectortest/
Here's a quick break down of a test run that was done earlier:
- Special Firefox 3.1 Build (73.8% - More details)
- Safari 3.1 (49.3% - No Fragment or Namespace support)
- WebKit Nightly (51% - No Fragment or Namespace support)
- Opera Gogi - "ACID3 Build" (76.7% - No Fragment support)
- IE 8 (Can't run - the file is proper XHTML so it tries to download it.)
- Firefox 3, Opera 9.5, IE 7 (0%)
The work that is being done to implement the specification in Firefox can be seen on its associated Bugzilla bug. I'm shooting very hard to make sure that everything is in place so that this makes it in to the upcoming Firefox 3.1 release (the first alpha of which is due out in a couple weeks). The benefits that this will have for both JavaScript libraries and their users will be tremendous.
Tags: css, firefox, mozilla, w3c
16 Comments on 'Implementing a Selectors API Test Suite'
·
« Previous entries
