• input type=”email”
• input type=”url”
• inpu type=”number”
• input type=”range”
• input type=”date”
• input type=”time”
• input type=”datetime”
• input type=”week”
• input type=”month”

Then Mark discusses input type=”search”:

Andy Lyttle wants to standardize one particular feature of <input type=”search”> (which is already supported by Safari, but not standardized): placeholder text for input fields. The text would initially display in the input field (possibly in a stylized form, smaller font, or lighter color), then disappear when the field receives focus. Lots of sites use Javascript to achieve this effect, but it is surprisingly difficult to get right, in part because no one can quite agree on exactly how it should work. Mozilla Firefox displays the name of your current search engine in its dedicated search box until you focus the search box, at which point it blanks out and allows you to type. Safari’s search box is initially blank (at least on Windows), and only displays the name of your default search engine after it has received focus and lost it again. Google Chrome’s “omnibox” displays “Type to search”, right-justified, even when the omnibox has focus, then removes it after you’ve typed a single character. Adding an <input placeholder> attribute would allow each browser on each platform to match their users’ expectations (and possibly even allow end-user customization) of how placeholder text should work for web forms. Discussion threads: 1, 2, 3. So far, there is no consensus on whether this should be added to HTML 5, or what the markup would look like.

And, he finishes with some interesting posts:

• Following up on last week’s article on clickjacking, the security researcher who discovered (and named) it has posted details of his discovery. Short version: it’s even worse than we thought, but vendors are working on it. Here’s a proof-of-concept against Adobe Flash that, quite literally, spys on you (via your webcam) without the usual warning dialogs; here’s Adobe’s response. NoScript now offers enhanced protection against some clickjacking attack vectors.
• Anne van Kesteren gives an update on IE 8’s support for HTML 5 and other emerging standards.
• Matt Ryall has a good article on HTML 5, headings and sections, which documents the differences between HTML 4 and 5’s header elements. My personal opinion: I once wrote a 500 page book in Docbook, a non-HTML markup language for technical writers. Docbook 3 had separate elements for <sect1>, <sect2>, <sect3>, &c, and it was a massive pain in the ass to cut-and-paste sections, or try to reuse them in different documents. Docbook 4 added a generic <section> element which can be nested indefinitely, and all those problems went away. Lots of web authors copy-and-paste HTML markup; anything that helps that “just work” is a good thing.

Here’s the first half of the talk on Vimeo:

Chris Heilmann: Maintainable JavaScript, part 1 from Bachelor-ict.nl on Vimeo.

And here’s the second:

Christian Heilmann: Maintainable JavaScript, part 2 from Bachelor-ict.nl on Vimeo.

A typical server-side web framework today includes three main components: a URL dispatching to some controller object scheme, a template engine, and a data mapping facility. Currently in Dojo, you’ll find that the latter two items already exist. dojox.dtl provides the first one, and dojo.data provides the second.

Given that Dojo already offers an implementation of the Django template engine, and that regular expression-based URL dispatch was a good fit for our problem at hand, I decided to base our URL dispatch on the model provided by Django.

You can see an example using the framework which uses these patterns:

To get this all going you do something like this:

Read the full article for details, and download the entire sample, for perusal.

• XDomainRequest: Microsoft unfortunately continues with XDomainRequest rather than making changes to XMLHttpRequest as other browsers are doing and as is being standardized by the W3C Web Apps Working Group. (Disclaimer: I am the editor of XMLHttpRequest Level 2.)

  Some agreement was made to at least support the same protocol on the server, namely using the Access-Control-Allow-Origin header as per Access Control for Cross-Site Requests. (Disclaimer: I am the editor of that draft too.) However, IE8 only supports * as value for that header, not an origin, e.g. http://annevankesteren.nl (test). Sunava pointed out that was because the W3C WebApps WG was still debating the matter. Here is hoping they will fix the bug as there is agreement on that syntax.

• HTML5 DOM Storage: localStorage and sessionStorage are now supported. Enumerating through them does not give the results I was expecting (I got "length" and "remainingSpace" back as well, besides the keys) and they still have a remainingSpace member that is not part of HTML5. Given that anything that gives some indication of space is highly vendor specific as it depends on encoding, compression, and type of device, they should really rename it to msRemainingSpace or some such or simply drop it.

  IE8 also supports an event named storagecommit that is not part of HTML5 which tells you when the data has been written to an XML backend format IE8 uses. The event object for used for the storage does not expose key, oldValue, and newValue. The url member is named uri and the source member is null rather than a reference to the Window object. Ouch!

• ARIA: Aaron Leventhal recently blogged about how ARIA in IE8 is a pain. (Aaron works for IBM making Firefox and Web applications accessible and is a member of the W3C PF WG which standardizes ARIA.) In short, when IE8 renders in super standards mode ARIA will work as everywhere else, otherwise you have to use Microsoft proprietary syntax. So not only do you need to upgrade your application code to be keyboard accessible and ARIA-enabled, you will also need to upgrade it from quirks to standards mode. Alternatively, you could take the easy way out and lock out other browsers. Not nice.

He did admit that he has "only played around with Internet Explorer 8 for an hour so" :)

Remy Sharp wanted to take the pastebin concept a step further, past the static posting of code. His idea, which he tossed around for 6 months, finally came to fruition in the form of JS Bin, a new pastebin site with a twist:

JS Bin is a form of paste bin, but with a twist. It allows you to also include the HTML and CSS to provide context to your pasty. As such, it means you can actually run the JavaScript and pass this on to a colleague to help to debug.

This is a great idea as it lets you troubleshoot your code while seeing immediate results. The feature list is well thought out as well.

• Save private snippet
• Remote Ajax debugging
• Snippet URLs run entirely on their own (i.e. without the JS Bin framework around them)
• Support to quickly inject major JS libraries including jQuery, jQuery UI, Prototype, Scriptaculous, Dojo, MooTools & YUI
• Saves state within the open window (i.e. refresh and the code doesn't reset)

The ability to inject many of the popular JavaScript libraries is especially important and I would highly recommend individual project teams to contact Remy directly to have their libs included.

To give this a run, I'd suggest going to the JS Bin site and putting it through its paces. In addition, Remy has produced two videos which go into detail on how to leverage JS Bin:

• JS Bin Video Introduction
• Ajax Debugging

Shane O'Sullivan has built a nice search mashup experience called Chofter. It uses all things Dojo, including:

• Layouts, Dialogs, Menus and ContentPanes for the user interface.
• dojo.data and dojo.rpc for data transfer.
• dojox.dtl (Django Templating Library) for transforming search data into visuals.
• dojo.fx and FisheyeLite for eye candy

He started with the snippet:

And then he rev'd it in different ways and captured the output.

His conclusion?

What I think of these results:

• I don't know what Firefox is doing in case 2, and for some reason Safari Nightlies seem to be following it. Maybe it's just beyond my understanding, but case 2 is not supposed to be different from case 1. Why does case 2 operate in global scope? If window.eval is different from eval, case 3 shouldn't all have given errors. Someone please help me understand that $hit.
• Case 4 makes sense, but that's a non-standard behavior in Firefox. Understandable that no one else exhibits it.
• IE baffles me in case 5, and Chrome seems to ape it. In this scenario, the anonymous function is supposed to have the global scope - so, in this case, this should point to the window. WTF is happening here!
• Consistent with case 2 above, Firefox and Safari Nightlies continue to display weird behavior in case 6. For some reason, in these two cases, the eval operates in the global scope.
• Now, I have no idea why, but only cases 8 and 9 seem to really work at all. This is despite Doug Crockford going on and on about not using with constructs. It's also despite being beyond (my) understanding about why the with should make any difference to the eval, since eval is part of the window object.

All in call, if you are going to be evaling JavaScript (not JSON), and you want the eval'd code to run in the global scope, you should use the with block around the JavaScript snippet. Or else, you can lose a lot of hair handling cross-browser issues.

• SDK Programming for Web Developers delves into the introduction to Objective-C and MVC
• Creating a first project in Xcode: Hello,
  World! gets you used to the tool chain

I hope to see books that focus on what you can do with the Web APIs too of course ;)

This article is based on iPhone in Action, to be published January 2009. It is being reproduced here by permission from Manning Publications. Manning early access books and ebooks are sold exclusively through Manning. Visit the book's page for more information.

Gasman has created Antisocial, a very enjoyable demo of Canvas doing fake 3d and 2d along with that ZX Spectrum sound that you loved as a kid.

Check out the tool to see where the magic happens, and make some music, Spectrum style!

I feel like we have been light on showcases recently, so please email us if you have seen a cool use of Ajax that we haven't picked up on!

First, our own Christian Heilmann took a table based layout, and in short order turned it over to the light via YUI Grids and CSS.

He took this:

And it quickly became this:

He has made the code available, and is asking if people want more information. I would love to see more of this content myself... people that know their stuff explaining the how and the why.

This leads us from CSS to JavaScript. The Prototype team put out a call for pimping. Send them some code, and they will show you how they would write it, inevitably in that Prototype "kinda like Ruby JavaScript" style. I look forward to the first showing!

Lack of support for XHTML is a fact of life on the web in 2008. Prior to the 3.0 series of Firefox the XHTML processor in Gecko was so poor that Mozilla’s own engineers recommended against it[27]; no version of Internet Explorer up to, and including, IE 8 support XHTML at all, and a number of other browsers such as Lynx were never written to handle XML in the first place.

The above quote comes from XHTML?—?myths and reality by Tina Holmboe, a member of the XHTML Working Group.

It is a nice piece that delves into:

1. Introduction
2. The Purpose of XHTML
3. XHTML and the Content Type
4. Strictly XHTML
5. Lack of support
6. Content–Negotiation
7. Recommendations

The Jaxer team has released a release candidate for Jaxer 1.0.

Here a synopsis of all the new features and improvements that have gone into this latest release candidate:

• Jaxer.Sandbox: HTTP-level control; support readyState, toHTML, waitForCompletion
• Built-in, extensible dispatching for RESTful and RPC service requests
• Fast, native JSON support
• Improved APIs for HTTP Request and Response
• More flexible handling of application configuration
• Many bug fixes, smaller improvements, and cleanups

They are moving pretty fast, so are looking for feedback before they wrap up a final 1.0 release.

His article focuses on the latest updates to the fish, SquirrelFish Extreme:

A popular technique that is gaining traction amongst JavaScript engine implementers is that of optimizing the engine, while it's still processing the JavaScript code, to determine the "type" of the object that is being used. Since JavaScript doesn't include any sort of explicit type system JavaScript engines are frequently forced to check and re-check the values that they are handling, to insure their integrity. SFX rounds out the collection of other modern JavaScript engines, namely V8 and TraceMonkey, to provide this form of polymorphic inline caching. Interestingly, the idea for this form of caching comes from the Self programming language, the origin of many of the ideas in JavaScript (such as using prototypal inheritance instead of the more-common classical form of object inheritance seen in languages like Java).

JavaScript engines are serving as the test bed for new forms of dynamic language optimization. No other language is seeing this level of competition and rapid improvement that JavaScript is. This is optimal considering that JavaScript is one of the most widely-deployed programming languages available.

The SquirrelFish Extreme release currently stands as the fastest JavaScript engine [based on SunSpider] (although that's certain to change as healthy competition continues).

When I posted about using navigator.geolocation now the only support that I had was via Gears and the ClientLocation API. I wrote the shim to try to get you the W3C API no matter what, and today we have the first implementation in a browser, via Geode.

Geode is the latest project in Mozilla Labs that gives you that API in Firefox. Aza Raskin has a nice Food Finder application that ties it together with local search and maps.

Differences between Geode and Geolocation in Firefox 3.1

Geode and the Geolocation Services in Firefox 3.1 will use the same W3C API for Geolocation, meaning that the same Javascript code will work in both. The still-in-developement Firefox 3.1 version will allow the user to choose a geolocation service provider, which can either be a peripheral device like a GPS, or a web-based service provider like we’ve used in Geode. We’ll be using the feedback we get from Geode, as well as the feedback we see on the upcoming Firefox 3.1 Beta and Fennec Alpha releases, to refine the feature before shipping it in a future Mozilla product release. We’re particularly interested in ensuring that the final implementation is as sensitive to user privacy and choice as possible.

They also got some partners to start playing with this:

To kick off Geode, two other websites have started innovating with location. Both require accounts before you can try them out.

Pownce is a service that makes it easy to send stuff (music, photos, events, and messages) to your friends. Adding the power of location — where you are when you uploaded a photo or sent a message — paints a compelling picture that helps you discover friends and activities around you. Head there to see it in action (you’ll have to sign up for an account).

Yahoo! Fire Eagle is a service that acts as a broker for your location, creating a single place where any web service, from any device can get access to your last updated location. Fire Eagle integrates with Geode so that you’ll never have to manually enter your location again. Once you have a Fire Eagle account, you can see Geode working here.

The SourceForge project page has a brief overview and pointers to a tutorial, a widget showcase, and more.

XDomainRequest (XDR)

This is an object built from the ground up to make client-side cross-domain calls secure and easy. To reduce the chances of inadvertent cross domain access, this object requires an explicit acknowledgement for allowing cross domain calls from the client script and the server. Additionally, it reduces the need for sites having to resort to the dangerous practice of merge scripting from third parties directly into the mashup page. This practice is dangerous because it provides third parties full access to the DOM. All this comes with the added benefit of improved client-side performance and lower server maintenance costs thanks to the absence of a need for server farms for proxying.

During the Beta 1 timeframe there were many security based concerns raised for cross domain access of third party data using cross site XMLHttpRequest and the Access Control framework. Since Beta 1, we had the chance to work with other browsers and attendees at a W3C face-to-face meeting to improve the server-side experience and security of the W3C’s Access Control framework. As a result, we’ve updated XDR to be explicitly compliant with syntax and directives in the sections of Access Control for requesting simple public third-party data anonymously on the client! (Section 5.1.3 in the Access Control Process Model)

The updates to XDR from Beta 1 allow IE8 to request data from the domain's server by sending an Origin header with the serialized value of the origin of the requestor. IE8 Beta 2 will only return the response if the server responds with Access-Control-Allow-Origin: *, instead of allowing the XDomainRequestAllowed: 1 header as we did in Beta 1. Other changes include support for relative paths in the open method, and restricting access to only HTTP and HTTPS destinations.

Cross-document Messaging (XDM)

Cross-document messaging is another powerful cross-domain feature that I’ve blogged about in the past. Rather than make a backend request to a remote Web service, this allows sites hosting third-party IFrame-based "gadgets" or components to communicate directly with the parent, without unsafely violating the same site origin policy. This has advantages including improved performance and reliability, as developers don’t have to resort to workarounds that behave differently between browsers and have unwanted side-effects. This technique also removes the need for embedding third-party script in your page, lessening the chance of potential information disclosure vulnerabilities like the disclosure of your sensitive data (such as information in your social network profile) to third parties without your consent.

Beta 2 updates here include moving the onmessage handler from the document object to the window object to better align with the updated HTML 5.0 draft.

window.attachEvent("onmessage", HandleMessage);

We also replaced e.URI with e.origin, which is serialized form of “scheme” + “host” + “non-default port”. This is far safer as the URI can carry potentially sensitive information from the origin site that is not needed by the recipient for the decision to grant or not grant access.

if (e.origin == 'http://www.contoso.com') 
        { 
               // process message text     
        }

Finally, the HTML 5.0 draft also mandates that the targetOrigin parameter for the postMessage method now be made a required parameter, as opposed to an optional one. This will make it difficult for developers to make errors by requiring an explicit acknowledgement of the target destination of the message by specifying the origin <URL> or wildcard <*>.

 frameOther.postMessage("This is a message", "http://example.com");

DOM Storage

Today, web pages use the document.cookie property to store data on the local machine. Cookies are limited in capability by the fact that sites can only store 50 key/value pairs per domain. Furthermore, the cookie programming model is cumbersome and requires parsing the entire cookie string for data. While cookies are useful for marking transitions and changes on the client to the server as they are sent with the request headers in chunks of up to 4KB, IE8 brings better alternatives for scenarios involving persisting data on the client and distinctly maintaining sessions in different tabs. The W3C’s HTML 5 DOM Storage objects provide a much simpler global and session storage model for key/value pair string data. Sites can store data for the life of a tab or until the site or user clears the data.

Updates for Beta 2 include changing the name of the persistent globalStorage attribute to localStorage and the removal of the need to specify the domain when writing to the localStorage

// Store a key-value pair.
localStorage.setItem("FirstName","Sunava");

Finally, we also included improved support of the updated onstorage HTML 5.0 event returned when the storage is changed. We now return the URI when the local storage is changed, so that handlers for pages can know who carried out the latest transaction in the storage space in addition to providing the source to the window of the origin. Furthering the good news, the HTML 5.0 Working Group has incorporated the clear method, which we shipped in Beta 1, into the draft. This essentially allows for script to clear all items accessible in its storage space without having to iterate though the keys.

Connectivity Event

The navigator.onLine property and online/offline events now work on Windows XP as well as Windows Vista. The work to enable this was not trivial, as connection awareness in Windows XP is not quite as advanced as Windows Vista. That said, this will be extremely beneficial for developers, who we believe shouldn’t have to worry about OS differences. The value of connectivity events is particularly appealing when used in conjunction with the localstorage, where data can be cached in case of network loss!

XMLHttpRequest

Introducing the XDomainRequest object in IE8 hasn’t diverted our attentions from constantly tweaking and improving XMLHttpRequest, which will continue to be our flagship object for same-domain communications. Post-Beta 1 energies here have focused on a few bug fixes around reliability and working with the Web Apps Working Group to clarify and improve the draft specification, our compliance with it, and W3C public test cases. A timeout method introduced here in Beta 1 for the convenience of developers is currently being evaluated for adoption in the XMLHttpRequest spec.

// Sets timeout after open to two seconds.
xhr.timeout             = 2000;

ToStaticHTML, to JSON, and fromJSON

What do you do with the strings returned from third parties using XDomainRequest or Cross-document Messaging? In today’s world of increasing script injection and Cross-site Scripting (XSS) attacks, having the option of passing these through a safe parser comes as a welcome relief. As detailed in Eric Lawrence's post on Comprehensive Protection for IE8 Security, toStaticHTML provides a powerful way of sanitizing your strings by purging potentially executable content.

//Calling:
window.toStaticHTML("This is some <b>HTML</b> with embedded script following... <script>alert('bang!');</script>!");

//will return:
This is some <b>HTML</b> with embedded script following... !

In addition, IE8 Beta 2’s toJSON and fromJSON methods provide improved performance as opposed to non-native Javascript deserializers and serializers. Our implementation is based on the ECMAScript 3.1 proposal for native JSON-handling which uses Douglas Crockford’s json2.js API. In addition to the performance benefits of going native, the JSON parser provides a safe alternative to the eval() method, which has been a common and dangerous way to revive JSON objects, and could allow arbitrary script functions to execute.

Based on its performance on the regexes it does handle, WREC (WebKit Regular Expression Compiler) is indeed an awesome design. regexp-dna.js, however, is flawed and exaggerates SFX performance.

We could use nanojit to make a regex compiler for SpiderMonkey that would perform as well as WREC. But I don’t know if it’s worthwhile yet. Regex performance is much less important for today’s web than it is for SunSpider–I hope to link to a report on that in a future post.

That was the conclusion that David Mandelin of the Tamarin project as he looked into how "SquirrelFish Extreme (SFX) is kicking our butts so badly on regexp-dna.js."

I love David's posts, as they go into the real meat of the tech:

Technical details: the design of WREC. There are two main ways to implement regular expressions: using a backtracking matching engine, or by transforming the regex to a finite automaton (NFA, aka “state machine”), which does not backtrack. Most Perl-type regex engines, including both SpiderMonkey’s and WREC, follow the backtracking design. I don’t know the exact history of that choice, but at present it is much easier to implement features like group capture and backreferences in the backtracking design. Also, although some regexes scale only if implemented as NFAs, my tests suggest that many simple regexes, including those in SunSpider, are faster with backtracking.

As of this writing, WREC’s implementation strategy is dirt simple (which is a good thing). There are no transformations or fancy optimizations on the regex. WREC simply generates native code that directly implements the backtracking search. Thus, within a single match operation, there are no function calls, no traversals of regular expression ASTs, and few option tests, so almost all of the overhead is eliminated.

WREC’s code is very easy to read, so if you want to know exactly how it works, just read it in WREC.cpp. It’s also great example code for anyone implementing a compiler for a simple language like regular expressions. The basic plan is to parse the regular expression with functions named things like parseDisjunction (the | operator). Those functions directly call functions like generateDisjunction that generate the native code using the same assembler that the call-threading interpreter uses. There’s also the oddly named “gererateParenthesesResetTrampoline”. Inexplicably preserved typo, or watermark to detect copying of WREC code?

New Datastores

• dojox.data.JsonRestStore
• dojox.data.CouchDBRestStore
• dojox.data.GoogleFeedStore: A Google AJAX API powered data store for retrieving RSS and Atom feeds from Google.
• dojox.data.GoogleSearchStore: Data stores to interface Google's AJAX search services.
• dojox.data.PersevereStore: dojox.data.PersevereStore is an extension of JsonRestStore to Persevere's special features.
• dojox.data.S3Store: an extension of JsonRestStore to handle Amazon's S3 service using JSON data

New Projects in DojoX

dojox.analytics.Urchin

• A Google-analytics helper, which supports lazy-loading the Google Analytics API at any point during a page lifecycle.
• Allows you to post-onload include Google Analytics helper, and track Ajax-y pages via a simple API, with a very small overhead.

dojox.av

• New project for Audio/Video elements
• dojox.av.FLVideo: a player for Flash video files
• dojox.av.widget.Player: Dijit-based object for playing Flash media

dojox.embed

• A set of utilities that allow you to load/include Objects such as Flash and Quicktime.
• dojox.embed.Flash for Flash movies
  • Create proxy information for Flash movies implementing ExternalInterface through dojox.embed.Flash.proxy
• dojox.embed.Quicktime for Quicktime movies
• dojox.embed.Object—a Dijit that can be used via markup for any dojox.embed objects available.

dojox.io.windowName

• Provides secure cross-domain request capability. Sends a request using
  an iframe (POST or GET) and reads the response through the frame's window.name.

dojox.io.xhrPlugins

• This is a registry for creating alternate XHR handlers, for example
  you can register to use IE8's XDomainRequest or a proxy server to handle
  cross-domain requests.

dojox.lang.aspect

• dojox.lang.aspect is a new AOP library module for before/around/etc advice and other AOP features.
• See the blog post for details.

dojox.lang.observable

• Provides a form of getter/setter support to objects.
  Observable objects can be created such that all property
  reads, writes, and method calls will trigger listener functions
  so that you can create APIs where property interaction can be
  controlled and monitored.
• This relies on VBScript hacks for IE and is somewhat
  limited in functionality.

dojox.secure.capability

• This provides object-capability JavaScript validation.
• This is a validator to run before eval to ensure that a script can't access or
  modify any objects (like global objects) outside of those specifically
  provided to it.

dojox.secure.DOM

• Provides a DOM facade that restricts access to a specified subtree
  of the DOM.
• The DOM facade uses getters/setters and lettables to emulate the DOM API.

dojox.secure.sandbox

• Provides support for loading web pages, JSON, and scripts
  from other domains using XHR (and XHR plugins) with a safe
  subset library and sandboxed access to the DOM.

We updated the Google CDN to point to the new version too, and AOL has done the same.

3.0 has the following goals:

• Define an XML-based language that allows authors to write interactive
  multimedia presentations. Using SMIL, an author may describe the temporal
  behaviour of a multimedia presentation, associate hyperlinks with media
  objects and describe the layout of the presentation on a screen.
• Allow reusing of SMIL syntax and semantics in other XML-based
  languages, in particular those who need to represent timing and
  synchronization. For example, SMIL components are used for integrating
  timing into XHTML [XHTML10] and into SVG
  [SVG].
• Extend the functionalities contained in the SMIL 2.1 [SMIL21] into
  new or revised SMIL 3.0 modules.
• Define new SMIL 3.0 Profiles incorporating features useful within the
  industry.

The surrounding template stays put, and the red area changes when you have an action:

This is an old question: "When should you just reload the page?" In the sample application you see the trade offs. Every click causes a red "Loading..." indicator, and just the main area changes. The browser doesn't have any indication that something is happening, hence the need for the custom red indicator. You also then have to implement support for browser history, make sure that direct access works and the like. The positive is that you don't get a refresh flash, but is that enough to warrant the change?

One of the use cases on the page is the rich table component. That should definitely be able to refresh and page without the page changing, but when the main content gets swapped in, I start to question. What do you think?

Matt uses SiteMesh, a great technology that can knit together the look and feel, and can fit in very well in this kind of world. If a browser goes directly to a page it can piece together the entire page, but an Ajax request can come in and it can just send back the main content. Very nice.