(In the interests of avoiding cross-posting, I have only sent this e-mail to the whatwg list. The original e-mails were also crossposted to the IETF URI list and the rest-discuss list.)
This might be a good time to bring the FAQ to people's attention -- it covers what we ask people to go through when proposing new features: http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_the_spec.3F I encourage people to follow this process. On Sat, 15 Dec 2007, James M Snell wrote: > > The gist of the idea (which I believe may have been brought up before > but I'm not certain) is to allow the use of a URI Template in place of > the form element action attribute, and to use form elements to provide > the replacement values, e.g. > > <form template="http://example.org{-prefix|/|foo}?bar={bar}" > method="POST"> > Foo: <input name="foo" type="input" > > Bar: <input name="bar" type="input"> > </form> Why isn't the current form submission mechanism, with a redirect on the server-side, not acceptable? On Fri, 21 Dec 2007, James M Snell wrote: > > FYI... I've put together a quick prototype example [1] of a html form > using a URI Template [2]. The processing of the template is performed > in the onsubmit event of the form. > > - James > > [1] http://www.snellspace.com/wp/?p=832 > [2] http://www.snellspace.com/wp/?p=831 This is great -- why is it not enough? I have to admit to being a little concerned over the complexity of the URI template language as currently proposed. On Fri, 31 Oct 2008, Jerome Louvel wrote: > > It would just be easier to take advantage of them directly from HTML. > Right now, a Web form can already build a URI by adding query parameters > to the action URI of a GET form, why not go a bit further? Because it adds significant complexity to the browser platform, without really adding new functionality. > The benefit would be having more control over the construction of the > URI rather than just the query parameters. I could have a form with two > simple fields "a" and "b" and specify > "http://test.org/customers/{a}/reports/{b}" as the action URI. I don't understand why this is such a big deal. Such, the URIs are nicer, but, big deal. Just do a redirect if it matters that much. On Sat, 1 Nov 2008, Mark Nottingham wrote: > > Doing it in script precludes unintended reuse, e.g., for accessibility, > search engines, and so forth [...] Why would scripts preclude accessibility? And are you really expecting search engines to fill in forms that would use templates? (Some search engines fill in forms, but it's usually for searches, where the content would most properly be in the query component.) On Fri, 31 Oct 2008, Mike Schinkel wrote: > > What classifies as a "compelling use-case" in your mind? Something that can't be done without the feature. Something that allows authors to write applications that make users say "wow!", which they can't do today. On Sat, 1 Nov 2008, Mark Nottingham wrote: > > The benefits you're talking about seem to be all related to having more > flexibility in specifying URIs from forms. This is good and I agree that > in a perfect world, more flexibility would have been designed in from > the start. However, to put them into the mix while the machine is > running is a bit more complex; there needs to be something more > compelling (there's that word again) to drive adoption. Agreed. On Sat, 1 Nov 2008, Mike Schinkel wrote: > > Please PLEASE don't make us wait until 2032 or so for this! ;-) You can do it now with redirects or scripts. It's not clear to me that this is a feature that is important enough to ever be in the browser. On Sat, 1 Nov 2008, Mark Nottingham wrote: > > Because you're not introducing your idea to a new proposal that will > succeed or fail on its own merits; you're trying to get it into one of > the most widely-used formats in the world. As such, the barrier to entry > is higher; it has to be, or every idea that seems to be good would get > in, and HTML5 would be even more incomprehensible than it is now. Indeed, > I'm not the person to ask that, but frankly if you want the > functionality, go ahead and write the software, publish the site, > release the browser plug-in; the standards will follow if the minds do. That's how many parts of HTML5 have made it in. On Sat, 1 Nov 2008, Mike Schinkel wrote: > > Adding URI Templates to forms fills a large hole in the forms > architecture; This is very much a case of empowering serendipity as the > current form architecture current cannotly service the full range of > URLs that can be used. I'm asking for (most of) that gap to be filled. There are many many gaps, why is this an important one to fill? On Sat, 1 Nov 2008, Mike Schinkel wrote: > > I can understand, appreciate and respect that. FYI I lost patience with > the standard process a while back because it seemed that no matter my > input I was always told "no." Since I only found frustration, I gave > up. > > I'm participating again because Ian included me on a follow email on > this issue and because I really do want to see URI Templates become part > of HTML5. That said, I really have no idea how to go about getting > things accepted I think because I look for what could be and it seems > most standards people only want to see what already is? I encourage you to work with the browser vendors directly, as discussed here: http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_the_spec.3F > The irony is that if TBL had gotten this kind of resistance when he > tried to launch the web it never would have happened because he couldn't > demonstrate an existing use-case (Oh wait a minute, he DID get this kind > of resistance from the IETF, and it almost killed the web stillborne. > Thank god it didn't.) TBL did exactly what we're suggesting you do -- he wrote his own spec, wrote his own client, and wrote his own server, and put it out there. He didn't wait for a Standards Process to give him a stamp of approval. On Sat, 1 Nov 2008, Paul Prescod wrote: > > The Mechanize family of libraries would presumably be able to take > advantage of them as they do current forms. With mechanize you can ask a > headless client library to "load a page", "fill out some fields in a > form" and "submit" and it infers what HTTP requests to make based on the > form's structure. It cannot do this if the form is based upon > Javascript. So I'd say that's a generalized argument against depending > on Javascript for form capabilities, orthogonal to the question of how > rich forms' URI-building capabilities need to be. (Why can't Mechanize support script?) On Sat, 1 Nov 2008, Mike Schinkel wrote: > > 1.) I'm (hypothetically) the owner of atllogos.com and I want on provide > an HTML for to let visitors select from a drop-down to be able to visit > the Twitter users listed on http://atllogos.com/startup.html (Note that > "template" is a new attribute that is used for templates when no > "action" is specified): > > See these people on Twitter: > <form method="get" template="http://twitter.com/{name}"> > <select id="name"> > <option>sanjay</option> > <option>lance</option> > <option>stephenfleming</option> > <option>keithmcgreggor</option> > <option>melaniebrandt</option> > <option>jhaynie</option> > <option>MikeSchinkel</option> > <option>coty</option> > <option>wei_yang</option> > <option>mmealling</option> > <option>pfreet</option> > </select> > <input type="submit" value="Go!"> > </form> Why not just provide links, or use a redirect? What if the URI you have to compute is more complicated than just substitution, like some parts being dependent on others, or needing calculation, or whatnot? [snip 2, which was the same idea] > 3.) I am writing a blog post on Blogger.com about "Ride to Work Day" where I > am advocating people in the USA ride their motorcycle to work and I want to > include a form that let's them type in their ZIP code and check there > weather: > > <form method="get" template="http://www.weather.com/weather/local/{zip}/"> > <input type="text" name="zip"/> > <input type="submit" value="Check Weather!"> > </form> What if the user types something that isn't supported by weather.com, like the string "x"? Also, why can't you just do: <form method="get" action="http://www.weather.com/search/enhanced"> <input type="text" name="where"/> <input type="submit" value="Check Weather!"> </form> ...? That works today. > In the case of #1 and #2, spiders like Google can crawl those as well > but could not crawl them. That's especially important if someone decides > to architect a site using "clean" URLs and then use drop-downs in forms > to allow people to navigate to pages. If implemented in Javascript it > can't be reliably called but if URI templates were supported in forms it > could be. I don't really follow what you're saying here. I see no practical difference between URI templates and normal forms in terms of Google crawling the results. On Sat, 1 Nov 2008, Erik Wilde wrote: > > > > But the most of the web today won't be taking advantage of this for a > > long time. > > that is certainly true. but i think there are cases where this already would > be useful on today's web. I don't think anyone is denying that it is useful in certain cases. The question is whether it will be used widely enough to make it worth it. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'