I recently had an off-list email conversation with Ian Hickson, the editor of the Web Application Hypertext Technology Working Group specifications (i.e. HTML5 and WebForms 2.0). I was proposing to him that the current WebForms 2.0 be draft specification be amended to include a URI Template in the “action” attribute of the FORM element. Because I believe so strongly in the benefit of this proposal and because such things are inline with the Well Designed URLs Initiatitve was envisioned to advocate for, I decided to publish it to our blog and reference it in the WHATWG blog. The following is what I sent to Ian in email:
I really want to see WHATWG incorporate URI Templates for Web Form actions[1]. i.e.:
<form
action="http://foo.com/{make}/{model}/”
method="get">
<input type="text" name="make" />
<input type="text" name="mode" />
<input type="submit" />
</form>
If I type “Honda” and “Civic”, it will do a get to:
http://foo.com/Honda/Civic/
Instead of the only current possibility being something like:
<form
method="get"
action="http://foo.com/cars.php">
<input type="text" name="make" />
<input type="text" name="mode" />
<input type="submit" />
</form>
Which would produce the following for “Honda” and “Civic”:
http://foo.com/cars.php?make=Honda&model=Civic
To which Ian replied in two parts. Here is the first part:
“Why not just write a server-side redirector? That’s a trivial one to write. Four lines of code, maybe 10 if you make the recommended security checks first. You could also do it with a little bit of JavaScript.”
Unfortunately, a server-side redirector is not an appropriate solution in one case for the use-cases this proposal would address and doesn’t work for two others:
- Server-side redirection requires two round trips instead of one. I don’t believe any reasonably competent web architect for a high traffic site would allow a redirect for a high-traffic site. Consider any search engine such as the flagship offering for Ian’s employer; is Google likely to implement a redirect on every search request? Not likely. Server-side redirection reduces response time (by half?) and increases (doubles?) the number of concurrent requests that servers must handle. Using server-side redirection would probably also increase bandwidth requirements a measurable amount.
- It is not possible via HTTP to redirect the body of a POST. Consequently, the following use-case cannot be duplicated with a server-side redirect:
<form
action="http://www.myblog.com/{topic}/”
method=”post”>
<select name=”topic”>
<option value=”first”>My 1st Post</option>
<option value=”second”>My 2nd Post</option>
<option value=”third”>My 3d Post</option>
</select>
<input type=”text” name=”comment”>
<input type=”submit”>
</form>
- For those wanting to create a form to direct to a website they do not control, a server-side redirect is absolutely not an option. For example, assume that I wanted to run a page on my website that lets people navigate to the topics on the WHATWG blog using a FORM with a SELECT? It’s simply not possible as WebForms 2.0 is currently specified without Javascript (addressed in a moment), but would be easily possible using a template (note I left off the closing “</option>” tags for formatting reasons):
<form
action="http://blog.whatwg.org/{topic}"
method="post">
<select name="topic">
<option value="feed-autodiscovery">
Feed Autodiscovery
</option>
<option value="text-content-checking">
textContent Checking
</option>
<option value="checker-bug-fixes">
Bug Fixes
</option>
<option
value="significant-inline-checking">
Significant Inline Checking
</option>
<option value="charmod-norm-checking">
Charmod Norm Checking
</option>
<option value="proposing-features">
Proposing features
</option>
</select>
<input type="submit">
</form>
- My belief is having this capability would encourage a lot more linking of this type between pages on the web.
So yes, server-side redirection is possible in some cases but by no means all, and for those cases where it’s possible it is not optimal.
Moving on the Ian’s suggestion to use “a little bit of JavaScript” to meet this use-case, I will admit it is possible to use JavaScript but these are the drawbacks in viewing JavaScript as the solution for this use-case:
- JavaScript is simply not allowed in a wide variety of web applications such as wikis, forums, and other sites that solicit community content although many of these do allow HTML elements such as FORM.
- Some users disable scripting on certain sites, often by decree of their employers.
- Javascript’s cross-browser compatibility issues make it less reliable and people are far less likely to depend on it when money is at stake, and forms are frequently used in those contexts.
- “User agents with no scripting support” from Section 1.3 Conformance Requirements of the Web Applications 1.0 Working Draft (HTML5) that incorporates WebForms 2.0. Need I say more?
- Declarative code is far easier to debug than procedural code.
- Far more people know HTML than JavasScript given the much greater skill required to master the latter, and that is unlikely to change.
It’s interesting to note that in the preface to the introduction for Section 3 of the WebForms 2.0 Working Draft of 12 October 2006, the following note is made about how everything that repeating form controls offers can already be done in JavaScript and the DOM. The mere fact that they went to the trouble to include something as complex as repeating controls into HTML5 when it can be done with JavaScript and the DOM implies that well-known patterns in web architecture are better implemented declaratively instead of via JavaScript and the DOM:
Occasionally forms contain repeating sections. For example, an order form could have one row per item, with product, quantity, and subtotal controls. The repeating form controls model defines how such a form can be described without resorting to scripting.
Note: The entire model can be emulated purely using JavaScript and the DOM. With such a library, this model could be used and down-level clients could be supported before user agents implemented it ubiquitously. Creating such a library is left as an exercise for the reader.
So yes it is possible to use JavaScript in many cases, but it no where near optimal. Javascript should not be considered the solution for as well-defined and obvious patterns such as submitting to a clean URL.
To further drive home the value of this proposal, anyone monitoring the REST-discuss list for any length of time will see that most REST experts tend toward using (what I call :) well-designed URLs, i.e. URLs where the resource is identified by path instead of query string. With WebForm 2.0’s pending support of PUT and DELETE, it would be just short of a crime not to include support for posting to clean URLs in WebForms 2.0.
Since having this discussion with Ian via email it was since pointed out to me on rest-discuss by Mark Baker that my proposal as written would break the existing web so was a non-starter. For some reason I wasn’t thinking about that, probably because I was more concerned about getting Ian (who I like to call: Mr. “No“ :) to agree that URI Templates were needed. Still, the solution would be simple.
What follows are my examples from above recast using an optional template attribute that would override the action attribute for WebForms 2.0 compliant browsers. This would of course require the server to accept both query string parameters and clean URLs (and hopefully do a server redirect from the former to the latter), or the submit could be implemented using Javascript for older browsers when applicable. Note that I didn’t show an example using JavaScript but, as the WebForm 2.0 spec says “(that) is left as an exercise for the reader”:
-
<form
action="http://foo.com/model"
template=”http://foo.com/{make}/{model}/”
method=”get”>
<input type=”text” name=”make” />
<input type=”text” name=”mode” />
<input type=”submit” />
</form>
-
<form
action="http://www.myblog.com/topic"
template=”http://www.myblog.com/{topic}/”
method=”post”>
<select name=”topic”>
<option value=”first”>My 1st Post</option>
<option value=”second”>My 2nd Post</option>
<option value=”third”>My 3d Post</option>
</select>
<input type=”text” name=”comment”>
<input type=”submit”>
</form>
-
<form
action="http://blog.whatwg.org/topic"
template=”http://blog.whatwg.org/{topic}”
method="post">
<select name="topic">
<option value="feed-autodiscovery">
Feed Autodiscovery
</option>
<option value="text-content-checking">
textContent Checking
</option>
<option value="checker-bug-fixes">
Bug Fixes
</option>
<option
value="significant-inline-checking">
Significant Inline Checking
</option>
<option value="charmod-norm-checking">
Charmod Norm Checking
</option>
<option value="proposing-features">
Proposing features
</option>
</select>
<input type="submit">
</form>
So in summary I really hope that Ian, who definitely seems to be the gatekeeper for what goes into HTML5 and what doesn’t go into HTML5, can see his way clear to add this feature to WebForms 2.0. If his main issue with it is needing to have it written up for inclusion in the spec, I’m more than happy to help.