Re: [whatwg] HTML5 and URI Templates
On Sat, 1 Nov 2008, Erik Wilde wrote:
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.
i think this is the fundamental problem. you can do redirects if you
have everything under one control, the service provider and the one
building the forms. if this is not the case, then there is no way you
can do redirects. there is a service with a given URI scheme, and you
have to use it like that. can you build a form for it?
Just build a redirector on the same site as you build the form.
anyway, like i said above, html5 might decide not to be interested in
that functionality or might regard it as out of scope. all i want to say
here is that to see the value in that proposal, it is important to
depart from the traditional view of form clients and services always
being created by one entity.
I think it's an interesting proposal, but it doesn't seem ground-breaking
enough to really warrant additions in HTML5 at this point.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] HTML5 and URI Templates
(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
Re: [whatwg] HTML5 and URI Templates
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 Ian Hickson wrote: On Mon, 17 Dec 2007, Julian Reschke wrote: The HTML4 WG had this position about HTML as well. This position is what makes interoperability suffer, browser vendors having to spend lots of resources reverse engineering each other, and the resulting de facto error handling being suboptimal (hard to make extensions, for instance). Because URIs are just a syntactical construct. If there are common requirements for *user agents* how to handle things that aren't URIs but should have been, specify them for these user agents. For instance, why should RDF or XMLNS care about what *browsers* do with broken identifiers? That's pretty much the attitude that led to HTML5 needing to redefine as much as it does. But I guess we can always add URI processing to HTML5 as well while we're at it. If people want to send feedback on what they would have liked the URI spec to say, I can put it into the HTML5 spec in due course.
Re: [whatwg] HTML5 and URI Templates
Maciej Stachowiak wrote: Oh well. Are you really believing this? RFC2396 and RFC3986 define what a URI is. They do not and don't need to say anything about things which aren't URIs. It's been well known for some time that the URI and IRI RFCs do not correctly or sufficiently describe the way user agents must process URIs for compatibility with the Web. This is a bug in the RFCs. For the record: I totally disagree. It's not the job of the URI and IRI RFCs to describe how a user agent has to handle things that do not conform to the RFC3986/3987 syntax. On the other hand, if there's a problem with syntactically correct URIs/IRIs, please be more specific. BR, Julian
Re: [whatwg] HTML5 and URI Templates
On Mon, 17 Dec 2007 12:16:17 +0100, Julian Reschke [EMAIL PROTECTED] wrote: For the record: I totally disagree. It's not the job of the URI and IRI RFCs to describe how a user agent has to handle things that do not conform to the RFC3986/3987 syntax. Why not? The HTML4 WG had this position about HTML as well. This position is what makes interoperability suffer, browser vendors having to spend lots of resources reverse engineering each other, and the resulting de facto error handling being suboptimal (hard to make extensions, for instance). -- Simon Pieters
Re: [whatwg] HTML5 and URI Templates
Dnia 15-12-2007, So o godzinie 19:28 -0800, James M Snell pisze:
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 is this prefix operator needed here?
What is wrong with the URL http://example.org/?bar=input?
Chris
Re: [whatwg] HTML5 and URI Templates
It's just an example.
Here's another:
form template=http://www.google.com/search?{-join||q,num}
method=GET
input name=q type=text /
input name=num type=range step=1 min=5 max=100 value=5 /
/form
- James
Krzysztof Żelechowski wrote:
Dnia 15-12-2007, So o godzinie 19:28 -0800, James M Snell pisze:
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 is this prefix operator needed here?
What is wrong with the URL http://example.org/?bar=input?
Chris
Re: [whatwg] HTML5 and URI Templates
If a legacy browser comes across form template=... /, it would be no
different than if it came across a form element with no action
attribute; which means it would have the same impact as the html5 choice
to allow the accept attribute.
It should be possible for us to also do something like:
form action=http://example.org/form_processor;
template=http://example.org?{-join||a,b}
method=POST
input name=a type=text /
input name=b type=text /
input name=c type=text /
input name=d type=text /
/form
In a template-aware HTML5 processor, when the form is submitted, the
value of the action attribute would be overridden by the expanded URI
Template. In legacy browsers, however, the form will be posted to
http://example.org/form_processor. This would provide application
developers with a simple and hopefully transparent fallback for
down-level browsers.
HTML5 Post:
POST /example.org?a=wb=x
Host: example.org
...
c=yd=z
HTML4 Post:
POST /form_processor
Host: example.org
...
a=wb=xc=yd=z
- James
Henri Sivonen wrote:
On Dec 16, 2007, at 05:28, 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
What's the backward-compatibility story of this feature? (Both behavior
of URI templates in legacy browsers and ensuring that existing content
doesn't use braces.)
Re: [whatwg] HTML5 and URI Templates
On Mon, 17 Dec 2007, Julian Reschke wrote: The HTML4 WG had this position about HTML as well. This position is what makes interoperability suffer, browser vendors having to spend lots of resources reverse engineering each other, and the resulting de facto error handling being suboptimal (hard to make extensions, for instance). Because URIs are just a syntactical construct. If there are common requirements for *user agents* how to handle things that aren't URIs but should have been, specify them for these user agents. For instance, why should RDF or XMLNS care about what *browsers* do with broken identifiers? That's pretty much the attitude that led to HTML5 needing to redefine as much as it does. But I guess we can always add URI processing to HTML5 as well while we're at it. If people want to send feedback on what they would have liked the URI spec to say, I can put it into the HTML5 spec in due course. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] HTML5 and URI Templates
On 17/12/2007, James M Snell [EMAIL PROTECTED] wrote:
It should be possible for us to also do something like:
form action=http://example.org/form_processor;
template=http://example.org?{-join||a,b}
method=POST
input name=a type=text /
input name=b type=text /
input name=c type=text /
input name=d type=text /
/form
[...]
HTML5 Post:
POST /example.org?a=wb=x
Host: example.org
...
c=yd=z
HTML4 Post:
POST /form_processor
Host: example.org
...
a=wb=xc=yd=z
- James
Presumably people will use more than one templated form on their site,
but won't want lots of separate form_processors, so they would have to
use
form action=http://example.org/form_processor?{-join||a,b}
template=http://example.org?{-join||a,b}
method=POST
or something theoretically more correct like
form action=http://example.org/form_processor?%7B-join%7Camp;%7Ca,b%7D;
template=http://example.org?{-join|amp;|a,b}
method=POST
and then they can drop in a standard generic form_processor script to
handle everything automatically.
Most legacy browser users could be handled by a script which adds
onsubmit hooks to rewrite the 'action' attribute before submitting. (I
assume that'd work correctly in current browsers, but haven't tested
it). That would avoid the need for repeating the template URI twice
(with the associated risks of typing one of them wrong and not
noticing), if you don't want to handle scriptless users.
(How would the script know when it should do the rewriting, and when
it should leave everything to the browser? There's no obvious feature
test it can perform.)
Wondering about why this feature would be used:
If everyone who uses template URIs uses these backward-compatibility
additions (which they have to, unless they have no users), why would a
browser implement native support for template URIs? (The reason I can
think of is that it provides a slightly better user experience,
because you can go directly to the destination rather than being
delayed by a round-trip to form_processor, but that's no faster than
the scripted approach.)
If everyone who uses template URIs has to use these
backward-compatibility additions, why would they go to that effort
instead of using some server-side redirection logic to perform the
desired processing at the normal non-templated ugly URI? (Maybe it
makes the system cleaner if the server code has a nice URI-based API
and the client code does the mapping onto that, but I have no idea how
much difference it really makes. More significantly, it allows the
direct use of external resources that have sufficiently nice URIs but
don't have an equivalent GET/POST form-accessible API. I haven't seen
any other obvious useful uses yet.)
--
Philip Taylor
[EMAIL PROTECTED]
Re: [whatwg] HTML5 and URI Templates
On Dec 16, 2007, at 05:28, 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
What's the backward-compatibility story of this feature? (Both
behavior of URI templates in legacy browsers and ensuring that
existing content doesn't use braces.)
--
Henri Sivonen
[EMAIL PROTECTED]
http://hsivonen.iki.fi/
Re: [whatwg] HTML5 and URI Templates
On 16/12/2007, Henri Sivonen [EMAIL PROTECTED] wrote:
On Dec 16, 2007, at 05:28, James M Snell wrote:
form template=http://example.org{-prefix|/|foo}?bar={bar}
method=POST
Foo: input name=foo type=input
Bar: input name=bar type=input
/form
What's the backward-compatibility story of this feature? (Both
behavior of URI templates in legacy browsers and ensuring that
existing content doesn't use braces.)
Out of ~15K random pages from dmoz.org, I see two with braces in form action:
http://www.bornsvilkar.dk/ - form name=mainform method=post
action=BV.Main.BV.Browse.aspx?path=%2fwww_bornsvilkar_dk%2fbornsvilkaramp;layout={0685D858-53CA-4F7E-A3C8-53D1BD7F277D}
id=mainform
http://bip.wokiss.pl/margoninm/ - FORM
ACTION='index.php?pid=2opcje=a:1:{i:0;s:6:wyszuk;}' METHOD='POST'
ENCTYPE='multipart/form-data' name=wyszukiwarka style=margin:0px;
But the original example had form template which would avoid that
conflict. (The only template attributes I see are one page with
widget template and one with edittag:edit template.)
--
Philip Taylor
[EMAIL PROTECTED]
Re: [whatwg] HTML5 and URI Templates
Henri Sivonen wrote:
On Dec 16, 2007, at 05:28, 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
What's the backward-compatibility story of this feature? (Both behavior
of URI templates in legacy browsers and ensuring that existing content
doesn't use braces.)
Braces are not allowed in URIs (in case somebody forgot :-). That's
exactly why URI Templates can use them.
BR, Julian
Re: [whatwg] HTML5 and URI Templates
On 16 Dec 2007, at 14:12, Julian Reschke wrote:
Henri Sivonen wrote:
On Dec 16, 2007, at 05:28, 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
What's the backward-compatibility story of this feature? (Both
behavior of URI templates in legacy browsers and ensuring that
existing content doesn't use braces.)
Braces are not allowed in URIs (in case somebody forgot :-). That's
exactly why URI Templates can use them.
There are sites that rely on braces in URIs. You can't just go and
change their meaning, breaking the sites, specs be damned. If RFC 3986
defined what to do with non-conformant URIs, we wouldn't have this
issue.
--
Geoffrey Sneddon
http://gsnedders.com/
Re: [whatwg] HTML5 and URI Templates
On Dec 16, 2007, at 14:21, Philip Taylor wrote: But the original example had form template which would avoid that conflict. Oops. I missed that. Would the processing model be that the template attribute overrides the action attribute in template-aware UAs leaving it to the page author to provide a server-side compatibility redirector? -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: [whatwg] HTML5 and URI Templates
Geoffrey Sneddon wrote:
On Dec 16, 2007, at 05:28, 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
What's the backward-compatibility story of this feature? (Both
behavior of URI templates in legacy browsers and ensuring that
existing content doesn't use braces.)
Braces are not allowed in URIs (in case somebody forgot :-). That's
exactly why URI Templates can use them.
There are sites that rely on braces in URIs. You can't just go and
No, they rely on user agents not checking for syntactically correct
URIs. They aren't using URIs.
change their meaning, breaking the sites, specs be damned. If RFC 3986
defined what to do with non-conformant URIs, we wouldn't have this issue.
Oh well. Are you really believing this?
RFC2396 and RFC3986 define what a URI is. They do not and don't need to
say anything about things which aren't URIs.
So, if at all, it would be the job of the HTML spec to say what to do
with pages that use non-URIs where URIs are expected.
That being said -- James suggested template instead of action anyway.
BR, Julian
Re: [whatwg] HTML5 and URI Templates
Right. We avoid the issue by using a different attribute for the template. - James Julian Reschke wrote: [snip] That being said -- James suggested template instead of action anyway. BR, Julian
Re: [whatwg] HTML5 and URI Templates
On Dec 16, 2007, at 7:36 AM, Julian Reschke wrote: Geoffrey Sneddon wrote: change their meaning, breaking the sites, specs be damned. If RFC 3986 defined what to do with non-conformant URIs, we wouldn't have this issue. Oh well. Are you really believing this? RFC2396 and RFC3986 define what a URI is. They do not and don't need to say anything about things which aren't URIs. It's been well known for some time that the URI and IRI RFCs do not correctly or sufficiently describe the way user agents must process URIs for compatibility with the Web. This is a bug in the RFCs. Regards, Maciej
[whatwg] HTML5 and URI Templates
While I am certain some folks may not appreciate the departure from the
engaging and entertaining debate over video codecs, I wanted to offer a
minor feature suggestion [1] with regards to HTML5 forms and URI
Templates [2].
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
- James
[1] http://www.snellspace.com/wp/?p=827
[2] http://www.ietf.org/internet-drafts/draft-gregorio-uritemplate-02.txt
