HTML5 in the Web browser: HTML5 forms
The newest specs for HTML forms give programmers more control over data input and validation, while offloading much of the work to the browsersFollow @peterwayner
HTML5 forms: Authentication
One of the most tempting options brings authentication or certification to the form information, but it is still rather unformed and not very well implemented. The so-called
keygen element adds some form of cryptography using public-key encryption, but it is only partially implemented on Chrome, Firefox, and Opera, despite dating from the time of Netscape. The potential power is huge, but I think it will take several more iterations to find a good set of features that work the way that people expect.
The idea is to get the browser to offer a way to generate pairs of public and private keys automatically. Many programmers who've tried to use
keygen say it's confusing for the average person because it requires too much understanding of such details as the length of keys. There are also deeper issues about how users might move the certificates from computer to computer or how malware might target them.
In the future, the option might include a better way to automatically use a key pair to sign all data in the form, not just the challenge attribute attached to the
keygen item. This, of course, requires a more standard mechanism for creating the signature over all possible forms of data. The standard hash functions and message digests are probably a good place to begin. This will have to wait until the feature is more fully formed.
HTML5 drag and drop
The ability to drag HTML elements around and drop them somewhere else is an old option for Web designers who are willing to use their own libraries, but it's always been mired in some confusion. After Microsoft included drag-and-drop support in what was called DHTML in 1999, developers had to struggle with cross-browser problems. A number of good cross-browser scripts appeared over the years, and many sites use them, even though they seem to confuse the public, who tend to expect the items on Web pages to be somewhat fixed in place. I've often expected companies like Netflix to implement drag and drop to maintain lists, but they never seem to choose that path.
In any case, the HTML5 drag-and-drop spec smoothes away many of the browser differences. In theory, the cross-browser scripts won't be necessary as long as all browsers follow the standard in exactly the same way. All that you need to do is add the attribute
draggable='true' and the element can be picked up and moved.
Well, that's not quite all. If you want to do something with the dragged element, you must be able to handle at least seven different events that fire as it moves around the page. Struggling to deal with all possible options has driven some people to write long complaints about the complexity. (A "disaster" and "far from complete" are two early gripes.)
There are also some compatibility issues. Safari, for instance, requires a separate CSS entry to turn on dragging even after you add the
draggable='true' attribute. All of these issues point to the fact that someone is going to write a simpler drag-and-drop library that abstracts away much of this complexity and makes it as easy as adding the