Firefox 3.5 Articles

We’ve just launched Firefox 3.5, and we’re incredibly proud. Naturally, we have engaged in plentiful Mozilla advocacy — this site is, amongst other things, a vehicle for showcasing the latest browser’s new capabilities. We like to think about this release as an upgrade for the whole World Wide Web, because of the new developer-facing features that have just been introduced into the web platform. When talking about some of the next generation standards, the appearance of the number “5″ is almost uncanny — consider HTML5 and ECMAScript 5 (PDF). The recent (and very welcome) hype around HTML5 in the press is what motivates this article. Let’s take a step back, and consider some of Mozilla’s web advocacy in the context of events leading up to the release of Firefox 3.5.

Standardization of many of these features often came after much spirited discussion, and we’re pleased to see the prominent placement of HTML5 as a key strategic initiative by major web development companies. Indeed, exciting new web applications hold a great deal of promise, and really showcase what the future of the web platform holds in store for aspiring developers. Many herald the triumphant arrival of the browser as the computer, an old theme that gets bolstered with the arrival of attractive HTML5 platform features that are implemented across Safari, Chrome, Opera, and of course, Firefox (with IE8 getting an honorable mention for having both some HTML5 features and some ECMAScript, 5th Edition features).

Call it what you will — Web 5.0, Open Web 5th Generation (wince!), or, (R)evolution # 5, the future is now. But lest anyone forget, HTML5 is not a completed standard yet, as the W3C was quick to point out. The editor doesn’t anticipate completion till 2010. The path taken from the start of what is now called HTML5 to the present-day era of (very welcome) hype has been a long one, and Mozilla has been part of the journey from the very beginning.

For one thing, we were there to point out, in no uncertain terms, that the W3C had perhaps lost its way. Exactly 5 summers ago (again, with that magic number!), it became evident that the W3C was no longer able to serve as sole custodian of the standards governing the open web of browser-based applications, so Mozilla, along with Opera, started the WHATWG. Of course, back then, we didn’t call it HTML5, and while Firefox itself made a splash in 2004, the steps taken towards standardization were definitive but tentative. Soon, other browser vendors joined us, and by the time the reconciliation with W3C occurred two years later, the innovations introduced into the web platform via the movement initiated by Mozilla had gained substantial momentum.

The net result is a specification that is not yet complete called “HTML5″ which is implemented piecemeal by most modern browsers. The features we choose to implement as an industry are in response to developers, and our modus operandi is (for the most part) in the open. Mozilla funds the HTML5 Validator, producing the first real HTML5 parser, which now drives W3C’s markup validation for HTML5. That parser has made its way back into Firefox. It’s important to note that capabilities that are of greatest interest (many of which are showcased on this blog) are not only developed within the HTML5 specification, but also as part of the W3C Geolocation WG, the Web Apps WG, and the CSS WG.

The release of Firefox 3.5, along with updates to other modern browsers, seems to declare that HTML5 has arrived. But with the foresight that comes with having been around this for a while, we also know that we have a lot of work ahead of us. For one thing, we’ve got to finish HTML5, or at least publish a subset of it that we all agree is ready for implementation, soon. We’ve also got to ensure that accessibility serves as an important design principle in the emerging web platform, and resolve sticky differences here. Also, an open standard does not an open platform make, as debates about web fonts and audio/video codecs show. We’ve got a lot of work ahead of us, but for now, 5 years after the summer we started the ball rolling, we’re enjoying the hype around (R)evolution Number 5.

In today’s feature post we’ll talk briefly about three new CSS3 pseudo-classes: only-of-type, first-of-type and last-of-type. These are all very similar to the *-nth classes we covered in an earlier post.

first-of-type and last-of-type

These two pseudo-classes allow you to select the first and last item in a list of siblings within a particular element. You can use this to color the first item in a list, use opacity to make the last paragraph on a page fade out or a number of other things. Here’s an example that sets small caps on the first paragraph of a document:

#type-ex1 div:first-of-type {
    font-variant: small-caps;
}

only-of-type

only-of-type is similar to the previous two, but only selects an element if it has no siblings with the same name. Here’s a somewhat contrived example* that will hide single images inside of a div. If there’s more than one image in the div they will be visible:

.type-ex2 img:only-of-type {
    display: none;
}

And that’s it. Enjoy!

[ * Note: if someone can come up with a better example for only-of-type I'm all ears. There are very few examples of where this is useful. ]

Today we released Firefox 3.5, which as we said at the beginning of the 35 days project is a huge upgrade for both end users but also for the web.

In the past we’ve always published a list of web developer features for a release. But the feature list for developers for 3.5 is so long that we thought it might be useful to try and break it down into easy-to-swallow bites. And my suspicion, given the number of comments and the number of daily views this weblog gets, is that it’s actually been useful to people.

We’ve been writing articles on features to get people informed on what the changes are, but we’ve also been featuring demos to get people inspired. Some of them have been built by people at the Mozilla core, but the really great thing that we’ve seen is that people have started to show up and build demos for our project without us having to ask. I think that this points to the fact that people are really bullish on the future of the web. People want to see change, they want to see improvements and they understand that every individual has a role to play in that. To everyone involved, I say thank you. You’re helping to improve the web, one action at a time.

We’re about half way through our 35 days posts and we will continue to make posts. And we’re still looking for help. If you want to get involved, you’re more than welcome to join us. There’s always something that you can do – follow our twitter account, write a demo, document a feature or, really, just start using this stuff. We’re helping to write the future of the web and everyone has a part to play.

This post is from Les Orchard, who works on Mozilla’s web development team.

This post is by Olivier Rochard. Olivier does research at Orange Labs in France.

In HTML, the script element allows authors to include dynamic script in their documents. The defer attribute is boolean attribute that indicates how the script should be executed. If the defer attribute is present, then the script is executed when the page has finished parsing. The element is added to the end of the list of scripts that will execute when the document has finished parsing. Think about a FIFO processing queue : the first script element to be added to the queue will be the first script to be executed, then processing proceeds sequentially in the same order.

There is one very good reason for using the defer attribute: performance. If you include a script element in your HTML page the script must be evaluated immediately while the page is being parsed. This means that objects have to be created, styles must be flushed, etc. This can make page loading slower. The defer attribute implies that the script has no side effects on the document as it’s being loaded and can safely be evaluated at the end of the page load.

The defer attribute was first introduced in Internet Explorer 4, and added in the HTML 4 specification.

A simple test.

Here is a simple first test to see how the attribute works. The following lines are in the head element of a page:

‹script›
	var test1 = "Test 1 : fail";
‹/script›
‹script defer›
  	console.log(test1);
‹/script›
‹script›
	test1 = "Test 1 : pass";
‹/script›

If the defer attribute for the script element is correctly implemented the browser will:

1. Render the page.
2. Execute the second script element after all the others.
3. Display “Test 1 : pass” on the Firebug console.

If the console displays “Test 1 : fail” it’s because the scripts are executed in the same order as in the source code.

Note that the correct syntax for XHTML documents is:

<script defer="defer"></script>

A more advanced test

This second test is a way to see how the feature works in a webpage with multiple script elements inserted:

• Inline in the head and body elements
• External via src attribute in head and body elements
• With dynamic DOM insertion

Here is partial source code of a webpage that tests how defer affects script loading and parsing order:

‹!doctype html›
‹html›
    ‹head›
        ‹title› Test 2 ‹/title›
        ‹script› var test2 = "Test 2 :\n\n"; ‹/script›
        ‹script› document.addEventListener("DOMContentLoaded",
                function(){
                        test2 += "\tDOMContentLoaded\n";
                }, false);
        ‹/script›
        ‹script defer› test2 += "\tInline HEAD deferred\n"; ‹/script›
        ‹script› test2 += "\tInline HEAD\n"; ‹/script›
        ‹script src="script1.js" defer›
                // External HEAD deferred (script1.js) 
        ‹/script›
        ‹script src="script2.js"›
                // External HEAD  (script2.js)
        ‹/script›
	‹script›
            // Dynamic DOM insertion of a script (script3.js)
            head = document.getElementsByTagName('head')[0];
            script3 = document.createElement('script');
            script3.setAttribute('src', 'script3.js');
            head.appendChild(script3);
            // Dynamic DOM insertion of a deferred script (script4.js)
            script4 = document.createElement('script');
            script4.setAttribute('defer', 'defer');
            script4.setAttribute('src', 'script4.js');
            head.appendChild(script4);
	‹/script›
	‹script defer›
            // Deferred dynamic DOM insertion of a script (script5.js)
            head = document.getElementsByTagName('head')[0];
            script5 = document.createElement('script');
            script5.setAttribute('src', 'script5.js');
            head.appendChild(script5);
            // Deferred dynamic DOM insertion of a deferred script
            // (script6.js)
            script6 = document.createElement('script');
            script6.setAttribute('defer', 'defer');
            script6.setAttribute('src', 'script6.js');
            head.appendChild(script6);
	‹/script›
    ‹/head›
    ‹body onload="test2 += '\tBody onLoad\n';"›
        ‹script defer› test2 += "\tInline BODY deferred\n"; ‹/script›
        ‹script› test2 += "\tInline BODY\n"; ‹/script›
 
	... other body content ...
 
		<a onclick="alert(test2);">Launch test 2</a>
 
	... other body content ...
 
        ‹script src="script7.js" defer›
                // External BODY deferred (script7.js)
        ‹/script›
        ‹script src="script8.js"›
                // External BODY (script8.js)
        ‹/script›
    ‹/body›
‹/html›

When you click on the “Launch test 2″ link in the document a pop-up appears with a list in it. This list shows the order of script elements loaded during the session.

The test also displays the DOMContentLoaded and body.onload events when they are fired.

If the defer attribute is correctly implemented in the browser, all the deferred lines should be near the bottom of the list.

Results of the second test for each browser are below (deferred scripts are in green color) :

• The defer attribute behavior in the Firefox 3.5 browser is correct:
  1. Inline HEAD
  2. External HEAD (script2.js)
  3. Dynamic DOM insertion of a script (script3.js)
  4. Inline BODY
  5. External BODY (script8.js)
  6. Inline HEAD deferred
  7. External HEAD deferred (script1.js)
  8. Dynamic DOM insertion of a deferred script (script4.js)
  9. Inline BODY deferred
  10. External BODY deferred (script7.js)
  11. Deferred dynamic DOM insertion of a script (script5.js)
  12. Deferred dynamic DOM insertion of a deferred script (script6.js)
  13. DOMContentLoaded
  14. Body onLoad

• The defer attribute behavior in the IE 8 browser is erratic: the order is different at each reload :
  1. Inline HEAD
  2. External HEAD (script2.js)
  3. Inline BODY
  4. External BODY (script8.js)
  5. Dynamic DOM insertion of a script (script3.js)
  6. Dynamic DOM insertion of a deferred script (script4.js)
  7. Inline HEAD deferred
  8. External HEAD deferred (script1.js)
  9. Inline BODY deferred
  10. External BODY deferred (script7.js)
  11. Body onLoad
  12. Deferred dynamic DOM insertion of a script (script5.js)
  13. Deferred dynamic DOM insertion of a deferred script (script6.js)

• The defer attribute behavior in a WebKit browser (Safari 4.0) is erratic : the order is different at each reload :
  1. Inline HEAD deferred
  2. Inline HEAD
  3. External HEAD deferred (script1.js)
  4. External HEAD (script2.js)
  5. Inline BODY deferred
  6. Inline BODY
  7. External BODY deferred (script7.js)
  8. Deferred dynamic DOM insertion of a script (script5.js)
  9. Dynamic DOM insertion of a deferred script (script4.js)
  10. Deferred dynamic DOM insertion of a deferred script (script6.js)
  11. Dynamic DOM insertion of a script (script3.js)
  12. External BODY (script8.js)
  13. DOMContentLoaded
  14. Body onLoad

• The defer attribute behavior in the Opera 10.00 Beta browser:
  1. Inline HEAD deferred
  2. Inline HEAD
  3. External HEAD deferred (script1.js)
  4. External HEAD (script2.js)
  5. Dynamic DOM insertion of a script (script3.js)
  6. Dynamic DOM insertion of a deferred script (script4.js)
  7. Deferred dynamic DOM insertion of a script (script5.js)
  8. Deferred dynamic DOM insertion of a deferred script (script6.js)
  9. Inline BODY deferred
  10. Inline BODY
  11. External BODY deferred (script7.js)
  12. External BODY (script8.js)
  13. DOMContentLoaded
  14. Body onLoad

We hope that this has been a useful introduction to how the defer attribute works in Firefox 3.5. The tests above will also help you predict behavior in other browsers as well.

Resources

• The fixed bug 28293 – (defer) scripts with defer attribute not deferred : bug 28293
• The “JavaScript: Defer Execution” article on the WebsiteOptimization website : http://www.websiteoptimization.com/speed/tweak/defer/
• The script article on Mozilla Developer Center : https://developer.mozilla.org/En/HTML/Element/Script
• The “script element” part of the HTML 5 Draft : http://www.whatwg.org/specs/web-apps/current-work/#script
• The “Parsing HTML documents : the end” part of the HTML 5 Draft : http://www.whatwg.org/specs/web-apps/current-work/#the-end