As for all this debate about platforms - that's what markets are for. Platforms are market makers. Standards are different - they're forcing functions for markets. not market makers. Let's look at some HTML5 spec text for forms instead.
From the draft on extended form controls:
"The HTTP specification defines various methods that can be used with HTTP URIs. Four of these may be used as values of the method attribute: get, post, put, and delete. In this specification, these method names are applied to other protocols as well. This section defines how they should be interpreted."
The enormity of the consequences of HTML only allowing GET and POST cannot be overstated IMO. It's maybe the most damaging technical decision in the web standards space - ever. I see HTML forms as a root cause for the WS-* "everything goes over POST" debacle, a billion dollar industry mistake, at best.
What it gets wrong:
"If the specified method is not one of get, post, put, or delete then it is treated as get in the tables below."
Fail, on two counts. First a markup format that has impliciit defaults, ie, acquires values through the absence of specific markup tends to suck - example, I spent a few hours this week trying to figure out whether OpenSearch is compatible with RFC5005 - I'm not 100% sure but I suspect not - and it's because of impliciit markup. Specs in markup of the form "when the X is not present, assume a Y with value Z" are an antipattern. I have no idea how much time I've spent dealing with ill-advised attempts at acquisition semantics in XML, (aka "default values"), or in the Atom case, trying to argue them out over the years. But I think, a lot. Second, just allow the uniform interface and move on. Subsetting a uniform interface is - silly. I remember the Atompub WG seriously consider not using PUT and DELETE because lots of deployed infrastructure didn't support them. As of 2008, I still have to recommend X-HTTTP-MethodOverride as an option for protocols. Forms are not a special case of the Web's interface, imvho. Yes, I'm saying OPTIONS and MKCOL are valid values for the method attribute.
What would be nice - some text on server side validation. What happenss today is that servers often send back 200 Ok with validation errors. Server side validation is so common, I'd expect the 200 "Ok, but invalid" issue could get a mention. But maybe I missed it. Anyway, since the request was not ok, the 422 (Unprocessable Entity) would be a viable option for a failed validation.
5 Comments
Wouldn't the "default to get" be a result of HTML5's "Start by standardizing existing behaviour"? I think all current browser implementations I know of default to GET when there is no specified method, and changing that would "break the web", which I think HTML5 doesn't want to do.
Masklinn,
"changing that would "break the web", which I think HTML5 doesn't want to do."
But... "the web to break" isn't in HTML5, so I'm not sure that matters. Tbh, that's a personal design peeve with markup. The big thing for me would be allowing any HTTP method in a form - that would be a win.
I guess it's because most people developing for the web stilld don't see the benefit of the web as an architecture design. I'm reluctent to use REST but eventually the core principles of REST it is. I mean AtomPub is not REST but is thoroughly inspired by it.
I would bet that the folks behind HTML5 do understand those concepts better than most but they have made choices of a smooth upgrade from what we have now.
I love XForms and I'd say the guys behind it have answered the few shortcomings you highlight here, nonetheless XForms is still in the shadows of the web application land.
But let's face it, it will take another few years before we actually start seeing the benefit of all this because at the end of the day what matters to those producing applications is not whether or not it's done according to the book but how quickly it can get released and how many people will use it.
As long as the mind set has not changed we won't see much improvement. One good start would be to teach those concepts at University. I'm not sure the web as an application infrastucture is yet taught.
HTML5 defines anything sent as text/html as being HTML that can be processed using the HTML5 rules. The idea is that you can implement a Web browser by following the spec, without having to reverse-engineer other browsers (which is how browsers used to be written before HTML5).
The problem with allowing all the types is that what does it mean to have a form submit using the REPORT method? Or OPTIONS? Or CONNECT? Or any number of other valid methods? And what does it mean to submit to the FOOBARBAZ method?
I'm all for adding more actions, if they make sense, but we can't just say they all work, that would allow all kinds of crazy semantics that make no sense.
7sTfil <a href="http://ahhehtvalizi.com/">ahhehtvalizi</a>, [url=http://acsqrnpwsexf.com/]acsqrnpwsexf[/url], [link=http://esuuoogwgfvw.com/]esuuoogwgfvw[/link], http://ugtbeejfbvjf.com/