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'
February 5th, 2009
I gave a talk last week at Google (at the request of the excellent Steve Souders) all about the performance improvements, and new APIs, that are coming in browsers. I cover the new browsers, their JavaScript engines, their JavaScript performance, and then do a whirlwind tour of their new DOM methods and some of their new CSS APIs.
John Resig: Performance Improvements in Browsers @ Google
Presentation: Performance Improvements in Browsers
Tags: javascript, dom, browsers, html5
36 Comments on 'Talk: Performance Improvements in Browsers'
November 24th, 2008
While looking for improvements to injecting HTML fragments into a document (which I mentioned, in passing, when I looked at using Document Fragments) I decided to spend some more time with Internet Explorer's insertAdjacentHTML method.
This method has been in Internet Explorer since version 4.0 - as well as is in the current release of Opera - and allows you to inject fragments of well-formed HTML into a variety of locations in a document.
The locations work as such (I list the equivalent terminology):
.insertAdjacentHTML("beforeBegin", ...) |
before |
.insertAdjacentHTML("afterBegin", ...) |
prepend |
.insertAdjacentHTML("beforeEnd", ...) |
append |
.insertAdjacentHTML("afterEnd", ...) |
after |
The method is only available on DOM elements (which makes sense) and is easy to use:
var ul = document.getElementById("list");
ul.insertAdjacentHTML("beforeEnd", "<li>A new li on the list.</li>");
ul.insertAdjacentHTML("beforeEnd", "<li>Another li!</li>");
At first glance the method appeared to work well and seemed to be relatively fast. Two questions remained, though: How fast is it in comparison to using the Document Fragment technique I outlined before and does it work for all the strange use-cases that exist?
- I created a test case to compare the three types of injection: The type we've been using in jQuery prior to the upcoming 1.3 release, the new Document Fragment technique we'll be using in jQuery 1.3, and a case using insertAdjacentHTML (where applicable). While both the Document Fragment and insertAdjacentHTML cases were significantly faster than the old techniques used in jQuery the Document Fragment technique ended up being marginally faster in IE 6 (50ms vs. 80ms for insertAdjacentHTML).
- There's a huge problem with insertAdjacentHTML: It doesn't work on all HTML elements in IE 6 (specifically it doesn't work on table, tbody, thead, or tr elements). Having gaps in the functionality is very undesirable (attempting to use insertAdjacentHTML on those elements causes an exception to pop up in IE 6).
- It doesn't work on XML documents. Of course neither does innerHTML (at least not until browsers start to implement HTML 5 more completely). We're stuck doing the traditional techniques used in libraries like jQuery.
So why spend all this time talking about a method that is relatively half-baked in the main browser that implements it? Because it's going to be part of the HTML 5 specification. This means that we're going to see a larger number of browsers start to implement this method (and hopefully it'll encourage existing vendors to implement it more completely and efficiently).
Having browsers implement this method will dramatically reduce the amount of code needed to write a respectable JavaScript library. I'm looking forward to the day in which this method is more-widely available (along with querySelectorAll) so that we can really buckle down and do some serious code simplification.
Tags: dom, w3c, html5, ie
14 Comments on 'DOM insertAdjacentHTML'
August 9th, 2008
Decided to start something new with Dion Almaer (of Ajaxian.com fame) and Alex Russell (Dojo frame) - a podcast! We talk about the "Open Web" (the topics break down in to standards, development, JavaScript, tools - all sorts of things). We're working to get it up on iTunes (I'll be sure to update when it that's the case) but in the meantime you can subscribe to the RSS feed.
Dion has written up a nice overview of the first episode, which I've included below:
Welcome to the inaugural episode of a new podcast to cover news, happenings, and our opinions on the Open Web (download the Open Web Podcast episode one directly or subscribe to it). When I say “our” I am talking about the founding podcasters: Alex Russell, John Resig, and myself. It is a pleasure to be able to share air time with two of the real leaders of the Open Web, and specifically the Ajax space thanks to Dojo and jQuery.
What is the state of the Open Web?
That is how we started out the podcast, and we got to see very different opinions. John discusses the decentralization and new openness that we see across the Web. Alex was a little more wary, and talks about how he wants the Open Web to progress faster. He noted that a lot of the good work has been a little away from the client, and instead in the area of identity, transport, and formats.
We then move on to HTML 5, where we discuss items in Mark Pilgrim’s This Week in HTML 5 piece including Web Workers (think: Gears Workers), and the clarification of alt tag usage in the img tag to have you using alt="{diagram}" and the like.
We have a detailed chat about Web Workers, and where we see them being useful. John talks about issues around not being able to talk to the DOM, Alex talks about mashups, and I talk about some tests showing how they can help performance in a few areas. Matthew Russell did a demo using the Dojo 2d code at OSCON, and showed how he doubled the performance by pushing out computation into a Worker. John also talked about a special case for passing DOM fragments or the like to a Worker with special serialization. Of course, security is a concern for all of this.
John brought up the new data- embedding tactic that showed up in the HTML 5 spec. A conversation ensued around how you should separate your data from presentation. Is the DOM there to store data? Isn’t it a good place to keep it? Is “data-” just too long?
It is exciting to think that the W3C Selectors API will soon be implemented in Firefox 3.1, Safari 3, IE 8, and probably Opera 10. That seemed to happen pretty quickly. John and Alex talk about how this is going to mean a lot of chopping code from their frameworks, the increase in performance, and the subtle differences between the spec and how they were doing things.
The discussion leads to a new feature, named scoped CSS, that allows you to say “this CSS only works over here.” This could be huge, especially if you have an application such as a CMS, where people upload their own content that can mess with your application structure itself.
Next, we delve into the world of Firebug. John talks about how Firebug development is being bootstrapped by Mozilla and other contributors, and he discusses the upcoming versions and what you can expect. Stability and performance are top of the list. Don’t forget the Firebug Lite improvements too, which mean that you get more than just console to play with in non-Firefox browsers. I just posted the notes on that meeting, kindly taken by Steve Souders.
We talked about the Open Web Foundation, and Alex discussed what he would like to see come of it. He is optimistic, and thinks that the real test will be if we see the incubation of projects that really push the Web on the client side, as well as the identity side.
Finally, there is news in the Dojo community and Alex spills the beans. After over 4 years of service, Alex is stepping down as the project lead of Dojo, and handing over the reins to Peter Higgins who has shown great chops as both a commiter and an external leader. We wish Pete the best of luck! Alex isn’t sneaking off into the sunset though, as he talks about in his post on the subject, he will see be an active member of the Dojo community for a long time to come.
Finally, thanks again to John and Alex for taking the time to start this up with me. Please let us know what you think, and what you would like us to talk about.
Tags: html5, whatwg, w3c, podcast
10 Comments on 'Open Web Podcast #1'
July 13th, 2008
A new feature being introduced in HTML 5 is the addition of custom data attributes. This is a, seemingly, bizarre addition to the specification - but actually provides a number of useful benefits.
Simply, the specification for custom data attributes states that any attribute that starts with "data-" will be treated as a storage area for private data (private in the sense that the end user can't see it - it doesn't affect layout or presentation).
This allows you to write valid HTML markup (passing an HTML 5 validator) while, simultaneously, embedding data within your page. A quick example:
<li class="user" data-name="John Resig" data-city="Boston"
data-lang="js" data-food="Bacon">
<b>John says:
</b> <span>Hello, how are you?
</span>
</li>
The above will be perfectly valid HTML 5. This should be a welcome addition to nearly every JavaScript developer. The question of the best means of attaching raw data to HTML elements - in a valid manner - has been a long-lingering question. Frameworks have tried to deal with this in different manners, two solutions being:
- Using HTML, but with a custom DTD.
- Using XHTML, with a specific namespace.
The addition of this prefix completely routes around both issues (including any extra markup for validation or needing to be valid XHTML) with this effective addition.
On top of this a simple JavaScript API is presented to access these attribute values (in addition to the normal get/setAttribute):
var user = document.
getElementsByTagName("li")[0];
var pos =
0, span = user.
getElementsByTagName("span")[0];
var phrases = [
{name: "city", prefix: "I am from "},
{name: "food", prefix: "I like to eat "},
{name: "lang", prefix: "I like to program in "}
];
user.addEventListener( "click", function(){
var phrase = phrases[ pos++ ];
// Use the .dataset property
span.innerHTML = phrase.prefix + user.dataset[ phrase.name ];
}, false);
The .dataset property behaves very similarly to the the .attributes property (but it only works as a map of key-value pairs). While no browsers have implemented this exact DOM property, it's not hugely needed - the above code could be done with the critical line replaced with:
span.innerHTML = phrase.prefix +
user.getAttribute("data-" + phrase.name );
I think what is most enticing about this whole specification is that you don't have to wait for any browser to implement anything in order to begin using it. By starting to use data- prefixes on your HTML metadata today you'll be safe in knowing that it'll continue to work well into the future. The time at which the HTML 5 validator is integrated into the full W3C validator your site will already be compliant (assuming, of course, you're already valid HTML 5 and using the HTML 5 Doctype).
Tags: html5, data, dom, javascript
45 Comments on 'HTML 5 data- Attributes'
March 6th, 2008
Our day has finally come. CSS coders got some love with Internet Explorer 7 - us JavaScript folk got absolutely nothing. In fact, at last count, all we got were a couple new bugs to deal with (file:// requests not working via XMLHttpRequest and <object>.getElementsByTagName("*") always returning no elements).
Internet Explorer 8 is our release.
The first beta was pushed out today and it shows huge promise. It's already achieved way more than I would've expected and it's made me hungry for more. If you had bet me that Microsoft would be mentioning the phrases "ARIA", "SVG", and "MathML" in their release notes I would've lost.
Here are my thoughts on a bunch of the browser features:
W3C: querySelector
A super-fast way of finding elements based upon a CSS selector. The second browser to implement the selectors API has hit the market (behind a WebKit nightly release).
It's important to realize that any selectors here are completely reliant upon the browser's native selector implementation. IE8 is only shooting for CSS 2.1 support - which means that you really shouldn't be holding your breath for CSS 3 selectors. As I mentioned previously these blackbox APIs are going to be a source of never-ending hair-pulling and struggle going into the future.
HTML 5 Party!
I was hoping for some HTML 5-compliant features to land - well, hoping isn't the right term, perhaps 'feverishly expecting the worst' is more correct. However we can see that we've been graced with 4 full feature implementations from the spec - fantastic!
HTML 5: window.location.hash
Already supported fairly well by most browsers. Modifying window.location.hash changes the page URL and adds the page to the history (allowing for back-button simulation in Ajax applications). IE went a step further and broadcasts the hashchanged event (the first browser to do so, as far as I know).
HTML 5: DOM Storage
A feature that I discussed previously in which data can be persisted in a way that supersedes the use of primitive cookies storage. This has been in Firefox since version 2 but is absent from Opera and Safari.
HTML 5: postMessage
As I discussed previously postMessage serves as a way of communication across frames with simple text strings. IE 8, Opera 9, Firefox 3, and WebKit nightlies all support this feature - making it the only one with complete browser support.
HTML 5: Offline Events
As I've written about previously this is an easy way of detecting connectivity within the confines of JavaScript. With it we can write graceful offline Ajax applications. Firefox 3 and IE 8 appear to be the only browsers to support this feature.
XDomainRequest
This is an interesting feature for doing cross-domain requests but doesn't appear to conform to the existing Cross-site XMLHttpRequest work which is in Firefox 3. Even at that it appears to be quite crude - forfeiting any form of filtering or security controls for a simple boolean "yes/no" header.
Seeing this new API concerns me. The Cross-site XMLHttpRequest work may be in some flux, as some API points are still being hammered down, but it's doubtful that the resolution will end with something identical to what's being described by Microsoft.
DOM bug fix love
getAttribute/setAttribute have seen a major overhaul - in short: They now behave like they should and as they do in every other browser. The notorious issue of accessing relative/absolute href/src attributes is also resolved - which is just great. They also saw fit to add hasAttribute.
Also newly fixed/added:
.ownerElement and .ownerDocument - Finally we have a unified way of dealing with iFrames.getElementById returns elements by id - ONLY. Been such a long time coming, thank goodness.- Doing
getAttribute("checked") now returns "checked" instead of true.
- <button/> values are actually submitted now, instead of their inner text values.
- Dynamically created (or modified) radio buttons are now checkable.
I simultaneously feel both joy and anger in seeing these fixed. Happy that they're being released and anger for the fact that I had to struggle through them and that they now consume some portion of my brain.
W3C: Events
This is one area that is completely absent from this beta. We are still stuck with IE's attachEvent system - no addEventListener in sight. I don't know how serious they are about supporting Acid3 but it includes a test for addEventListener so they may want to consider it extra strongly.
I can partially understand their desire to keep their existing API but I don't understand why they have no interest in, also, adding addEventListener, etc. to complement what's there. I assume it's because they would now have to support concepts like event capturing.
I'm really disappointed with this. This should've been a top priority fix before implementing new psuedo-XHR systems like XDomainRequest.
JavaScript Language
The IE team has made some big improvements in improving garbage collection issues, memory management, and performance - all of which will be greatly appreciated in everyday applications.
Although, I mis-spoke slightly earlier: While IE8 is been great for JavaScript developers I was implying "JavaScript + DOM" developers. For pure JavaScript it's completely frustrating: There doesn't appear to be any new pure-JavaScript features in this release. I can only hope that we'll see more in a future beta release.
ARIA Support
This one completely blew me away. ARIA is a fantastic specification for empowering web applications with the ability to clearly communicate their intentions to a screen reader. The biggest hurdle with the effort, up until this point, has been the lack of IE support - obviously this will no longer be the case. Firefox, IE, and Opera all support ARIA now. The WebKit team doesn't appear to have interest in implementing this feature, which is a real shame.
Embedded SVG
Support for embedding namespaced elements within XHTML is now possible. This means that you can now do inline markup for SVG and MathML, amongst others, and have it "just work" (as long as you have their associated plugins installed). It's probably a bit much hoping for native SVG support, but I'll take what I can get.
Firebug for Internet Explorer
We finally have a heavily-Firebug-inspired tool inside Internet Explorer. To quote Joe Hewitt (creator of Firebug): "I couldn't be happier that Microsoft completely copied Firebug for IE8." I have to agree - a tool like this has been a long time coming and it's greatly appreciated. Only the Internet Explorer team would've ever been the ones to build this tool - there's simply too much information here that's unavailable to typical IE extensions.
Browser mode toggling
At first glance this feature makes the most sense for seeing if your IE 7 page will work ok in IE 8. In actuality, however, this will end up being very useful for developing a standards-compliant page (in IE 8, FF, Safari, Opera) and then toggling to see what the result is like in IE 7. This is so much better than the IE 6 to IE 7 jump where you have to keep your browser in a virtual machine in order for it to run side-by-side (according to Microsoft, at least - even though there were standalone solutions).
Bug Feedback
The Internet Explorer team is collecting feedback from select beta testers and publishing the bugs on a publicly-accessible site. This a huge step in the right direction (going from no communication to some is great). "Common" users are forced to vote for their "favorite" bugs to try and catch the eye of an IE developer. It's a strange situation but one that shows progress, at least.
Conclusion
In all I'm positive about this release, even with all the ups-and-downs. Seeing features like querySelector, ARIA, and postMessage helps to warm my frosty, bitter, heart. While there's still some major faux-paus in this release (no new JS langauge features?, no W3C events?, no CSS3 selectors?) I think we can, at least, be excited to see what happens in the next beta.
If nothing else the Internet Explorer team has done a great job of tackling many of the expectations of the development community - if they continue this trend I don't think anyone will be left disappointed.
Tags: ie, browsers, html5, dom, javascript
56 Comments on 'JavaScript in Internet Explorer 8'
January 24th, 2008
Assuming that it'll be a while before most browsers attempt to implement most of HTML 5 (a perfectly reasonable assumption) we need to start thinking of ways to tackle the creation and rendering of HTML 5 components in the meantime. Obviously, using the tools of JavaScript and CSS we can accomplish a lot.
However, there is one notch in our weapon: Internet Explorer doesn't know how to render CSS on elements that it doesn't recognize. For example, the following "blah" element (a fictional element) doesn't have any styling:
Result:
Thankfully, Sjoerd Visscher mentioned an interesting technique that could be used to force IE to use the specified CSS styling. Specifically, once you create a new DOM element (of the same name as the one in the document) all styling is applied. You don't even have to inject the element in order for this to occur. Observe the following:
Result:
This is very important. This now means that we can provide CSS styling for undefined HTML 5 element and allow Internet Explorer to handle it gracefully.
<figure/> element
Let's take a look at a simple example. Pretending that we wanted to set about implementing the HTML 5 figure element. The element is quite simple, only requiring some basic CSS markup (I'm not completely sure how a figure is supposed to look so I took some liberties here).
<html>
<head>
<style>
figure { border: 1px inset #AAA; padding: 4px; }
</style>
<script>document.createElement("figure");
</script>
</head>
<body>
<figure>
<img src="http://ejohn.org/files/jeresig-wordpress-sm.jpg"/>
</figure>
</body>
</html>
Result:
Using some basic CSS, and a single JavaScript DOM statement, we've now implemented at least part of the HTML 5 spec. While it won't solve everything, it is a promising technique, at the very least.
I did have some issues when I was testing this technique, especially with the styling of elements that are already defined elsewhere in the structure. For example, let's say you wanted to implement the legend child element of a caption. This ends up being really hard since the functionality and styling of legends are already defined for fieldsets by Internet Explorer. In my simple tests they became unstylable outside the context of a fieldset.
This is definitely a decent start, building our HTML 5 shiv, but it needs some more work and much more exploration. I hope to see this continued in the upcoming months as interest in, and availability of, HTML 5 begins to heat up.
Tags: css, javascript, ie, html5
21 Comments on 'HTML5 Shiv'
January 23rd, 2008
Remember the whole crazy Internet Explorer 8 meta http-equiv hub-bub, yesterday? There was one post in all of that mess that was really, really, important.
To sum it up: Internet Explorer 8 will support DOCTYPE switching for new DOCTYPEs (like HTML5).
"Steve": Are there any doctypes that do not require this new meta tag to render with the IE8 rendering engine?
Chris Wilson: @Steve - sure. Any unknown (i.e. not widely deployed) DOCTYPE. HTML5, for example.
This really does change any frustration that someone should have concerning the new meta tag. This means that you can write your web pages in a completely standards-based way (CSS, HTML5, JavaScript) and not have to use a single browser-centric tag in order to do so.
For those of you who aren't familiar with the HTML5 DOCTYPE, it looks like this:
<!DOCTYPE html>
You'll note that it's significantly simpler than most DOCTYPEs that you've seen - and that was intentional. A lot has changed in HTML5 in an attempt to make it even easier to develop a standards-based web page, and it should really pay off in the end.
What's nice about this new DOCTYPE, especially, is that all current browsers (IE, FF, Opera, Safari) will look at it and switch the content into standards mode - even though they don't implement HTML5. This means that you could start writing your web pages using HTML5 today and have them last for a very, very, long time.
If nothing else, this should be a good excuse to look through the changes in HTML5 and familiarize yourself with what's in the pipeline for browsers - Internet Explorer included.
I really, really, wish this was made clear yesterday - it would've avoided a whole lot of pain and suffering on the part of the Microsoft Task Force of WaSP and of the Internet Explorer team as a whole. I'm really glad that this is happening, though - the future of standards-based web development still looks quite bright.
Tags: browsers, html5
34 Comments on 'HTML5 DOCTYPE'
·
« Previous entries
