>THE WEB WAS born to publish documents—in particular, physics papers from CERN, the great laboratory where Tim Berners-Lee, [...] I have argued many times, to the despair of anyone within range, that the <form> element was a pivot point for the entire technology industry. It is what changed the web from a read-only medium for physics papers into a read-write medium for anything.
Tim Berners-Lee also invented the HTTP protocol. HTTP 1.0 had the "POST" method and HTPP 1.1 added "PUT". So the read-write capability of the web was there from the beginning. TBL also said the web was meant to be read-write: "I hope I do not have to motive here the fact that the Web in general should be read-write."[1]
If we use Paul Ford's framework that the "web" was meant to be read-only documents, what's the correct intended uses for POST and PUT? The writeback specification was already present at a lower level than the <FORM> element in HTML.
But we have to look at the macro forces beyond HTTP+HTML and consider if a read-only web was realistic. Before 1989 Tim Berners-Lee protocols, older online services like Compuserve and Prodigy already let users do shopping and buy airline tickets. The underlying desire for bi-directional flow of read+write to enable transactions was proven before the www was invented. Therefore, even if TBL himself didn't put write capabilities into the spec, others (maybe Netscape Navigator or Microsoft IE) would have added that capability in as an extension which becomes a defacto standard that everyone adopts. (E.g. Industry adopts MS IE's XMLHttpRequest())
Would the world really want an open platform like HTTP+HTML to have less functionality than the closed commercial services like CompuServe and Prodigy that already had read+write?
An alternative history without <form> would likely have involved far more <applet> than the one that actually happened. Still talking through those http verbs you mention and not through custom protocols I think, because proxies were so common.
Imagine instead of HTML, we had something like GIT... a collection of elements that make up a document, possibly spread across many files. When you loaded a page, it was like git clone. Your form would be locally saved (git commit), and you could optionally push those changes back (to give them your filled in form). Future updates to that same local form could be pushed at any future time.
--- Better yet
Imagine if the form element only took a URL of the completed form. You'd get the form, fill it out, save it on a server, and push that repository address to the form's input handler on it's original server. (Much like a pull request)
If HTML didn't have a <form> tag, then HTML and the web would still be a fairly marginal technology, and something else most likely would have existed where all these problems occurred. Maybe we'd all be complaining about how IRC is radicalizing people or something.
A repository full of static documents isn't really all that interesting. That's basically a library on a computer. Even in the very earliest days of the web, people were drawn to interactivity, whether it was early online stores, web forums, or even little interactive bits like comment sections on blogs or things like livejournal.
Originally HTML just had the <isindex> element, which was very similar to Gopher's primitive "search" functionality. Adding the <form> element with named input fields was a pretty obvious next step, and the fact that HTTP/HTML evolved to support it while Gopher did not says quite a bit about the culture behind these two protocols.
I know what we would have had if not for the form element: MSN [0]
> Originally named The Microsoft Network, it debuted as a proprietary online service on August 24, 1995, to coincide with the release of Windows 95.
MSN was a direct competitor to the internet (and AOL) despite Microsoft’s famous pivot a couple of months earlier [1]
> Realizing his company had missed the boat in estimating the impact and popularity of the Internet, Microsoft CEO Bill Gates issues a memo titled, “The Internet Tidal Wave,” which signaled the company’s focus on the global network.
Here in Australia, Microsoft teamed up with Telstra and tried really hard to shut down the emerging ISP scene (source: I was one of those ISPs)
> If people evolved like technology, you’d be 6,000 lizards, 30 chimps, and a couple Neanderthals all glued together with an anguished human face stretched across it as a “visual refresh.”
Well, actually there's still quite some old DNA in our genes, and we still go through various past forms as an embryo. Also we still got a tailbone despite not having a tail anymore, and a lot of similar cruft.
I get uncanny valley feeling whenever I look at an article from corporate clickbait farms. are these even written by humans? it reads like a regurgitated twitter diarrhea
I wouldn't have even clicked the article if I had noticed the domain it was coming from, and I regret the time I've wasted trying to parse this garbage
I think the form field certainly influenced the particular technical evolution path the web and internet took, but I also think it's not the reason we have social networks or e-commerce. Those were extremely compelling usecases even before the web and I don't think any particular technology was the reason, they got so big. That was probably more due to economic or social factors.
My guess is even without the form field, someone would have eventually tried to hack interactivity via some "stateful" links or something.
If Berners-Lee and co had somehow adamantly defended the "web of documents" idea, interactivity and e-commerce would probably have gone through other technologies, e.g. email or IRC.
Though I think it would be interesting to imagine an alternate universe where most of the effort and development went in those technologies and not HTTP.
You can see the same dynamic on precursor systems. Half the complexity in ANSI escape codes for dumb terminals exists to provide form support (and some features added to terminals like ‘terminal status report’ exist to make forms easier to implement). The French Minicom system was built to deliver interactive forms over the phone line to terminals in people’s homes; in the UK there was the similar Prestel, which was mainly used for commercial UIs (huge in the travel industry), and which was basically ‘teletext plus form fields’.
Heck, even print technology implemented ‘forms’ technology - there is a standard UX affordance of a dotted line with scissors drawn on it to tell you that a piece of printed material supports cutting out a form, filling it and mailing it in. These forms were showing up in magazines, on cereal packets, back for over a century… the catalog industry was built on this tech.
Basically, if you create an information distribution medium, someone will turn it into a form delivery platform. It’s inevitable.
Did any terminal ever implement the ANSI escape codes for block mode (i.e. form) fields?
The block mode terminals on IBM mainframes (e.g. the 3270) have all the functionality of a basic HTML form if you squint hard enough: the screen is divided into form fields and labels, the user can fill out the fields (and tab the cursor between them) while the terminal is offline/not communicating with the server, and then when the user presses one of the special 'submit' keys the terminal sends all of the data from the form fields to the server and awaits instructions on what to do next.
The 3270 even had hidden fields, so the server could stuff a bit of state information (like a session ID) into the form, which the terminal would dutifully echo back to the server when submitting the form....
It's a very different style of interaction as compared to the conventional Unix/PC character-by-character terminals, and leads to some pretty weird user interface conventions:
https://www.youtube.com/watch?v=9qwFSJZSjeA
Oh that is interesting - I only worked directly with a few terminal systems and never twigged that the 3270s were doing anything fundamentally more sophisticated than WYSE or DEC vt200s. I do remember tabbing between fields on an IBM3090 library catalog search form, though and it being basically an edit and submit process.
Yes, and the right of assembly was a bad idea because it allows people to spread ideas we don't like.
The web was specifically made for allowing people to submit and share content. The problem isn't that this included a way to submit content, but rather that we expect people to behave in a certain way. In practice humanity refuses to have it's behaviour to be defined and standardized. If you think something is bad because it allows people to exhibit irrational behaviour then you yourself are the one to blame for expecting people to conform to your own expectations regardless of the options made available to them.
Technocrats aren't going to invite you to their cocktail parties with that attitude! Since they're in control of an ever increasingly large share of our civilization, their desire for cogification of everything will keep on increasing.
In control how, moderation of social media and the rules/policies of other websites? Was it better when we all got our news and opinions in one direction from media conglomerates?
If we are looking for stuff that really changed the direction of the web, it is online advertisement.
Once you could reliably turn views into money, the web became more and more about “engagement”. Couple that with machine learning that optimizes engagement, and you know the rest.
Adding interactivity was not a mistake, requiring markup to reside with the text being marked up was the real disaster.
Imagine a world limited to Windows BMP images and MS-PAINT, That's how I feel about HTML and web browsers. In that world, GIMP would seem like an impossible dream, just like the Memex does in ours.
It is possible to separate out source text, annotation, and code into separate layers, and even separate sources. You should be able to take a file, and produce 5 different views of the same file without changing it, or making a copy.
Just like GIMP, if you need a flat file, that's what Export_As is for. I want a world where HTML is obsolete old junk.
> What forms enable are transactions. Transactions of all kinds—commercial or social—can be consolidated into platforms, and platforms are where you find your margins.
You know what, <form> was a mistake. Let's replace it with something like <div style="display: form; action: url(/process.php); -x-form-method: get"><span style=" display:textbox; -x-form-name: username">Username</spam></div> instead. Much better.
> Could we have created a <form> element that made it easier for small local manufacturers to sell online instead of Amazon rolling everyone up? How would that have worked? A text box that had some kind of privacy control built in, so that all our passwords wouldn’t leak?
To quote the late great Douglas Adams, "Many were increasingly of the opinion that they'd all made a big mistake in coming down from the trees in the first place. And some said that even the trees had been a bad move, and that no one should ever have left the oceans."
I don't know why I find articles like this so annoying, but in accordance with Betteridge's law of headlines[0], the answer is no.
>Here’s the thing: If it hadn’t been <form>, it would have been another element—maybe one with a more accurate name, like <money-vacuum> or <robot-food> or <privacy-destroyer>.
This sums up pretty much the entire article in that A) the form tag allowing the web to be a two-way street for data probably would've been filled by another feature, and B) the author is really lamenting about the tracking/anti-privacy/dark pattern world that the web has become. I completely understand the frustration, but it's certainly not an element's fault, but the fault of all the various players who have evolved the web over 25-30ish years. It might be more beneficial to actually explore that than blaming an html element.
>The web was born to distribute information on computers, but the technology industry can never leave well enough alone.
That's called progress.
FWIW, I'd probably say XMLHttpRequest "caused more damage" than the form tag, but I also don't think it's all that worthy of a discussion.
Well, I don’t think that Amazon, Twitter, or Hacker News were mistakes. I am enjoying the interactive web, and this is what I would have imagined in 1998 when I have developed a first Web application in Perl/CGI. Things are going fine.
<form> is very generic construct, it's a constructor the same way programming language constructing data of type. Form is also a function call with inputs as parameters. It's inevitable IMHO.
The entire web is just an inner platform attempting to recapitulate the general purpose computing available to desktop computers for decades, without much supporting the justifcation for replacement.
Journalists can't write about something like the <form> element without talking about Elon Musks' tweets. It's an unhealthy obsession and I'm kinda sick of hearing about it.
He's got a love-to-hate personality who is able to capture the limelight of journalist. This makes him seem like a firebrand to suckers who love him. They play off each other, making him into a massively famous celebrity.
Paul Ford must spend a non-negligible amount of time sitting around thinking: “What’s the dumbest thing I could get Wired or Bloomberg to publish?”
And to be absolutely pedantic: He shouldn’t be mad about forms and inputs, they can be used with the read-only web (GET params) and have client-side only uses (calculations.)
Given what he’s trying to say, the headline should be: “The ‘HTTP POST’ Method Created the Modern Web. Was It a Big Mistake?”
But what’s a Paul Ford article without a misdirected a torrent of bromide to keep things flowing?
You don't need a `HTTP POST` to update server state this can be done with cookies/headers or the uri (granted doing so in the URI is a CSRF risk). Point being, client originated updates are an inevitability as long as we allow variable data to be passed from the client to the server.
This is one of the most vacuous articles I have come across in quite some time, all wrapped up in rhetoric and presented as if it were some profound insight. It's not. Not only does it get the tech details wrong (POST allowed read/write capability pretty much from the beginning, <form> wasn't the start of it) but it would be equally accurate-- and useless-- to point to the keyboard as the culprit. Or taking a step outside of tech, complain that human hearts are the #1 cause of heart attacks & nerves as the arch-villain behind all physical pain.
I kept reading, thinking that there must be something somewhere that would tie things together in any meaningful way, but nope, nothing. It could be transplanted to The Onion with only a few modifications and fit much better there as some type of absurdist piece of humour.
>This is one of the most vacuous articles I have come across in quite some time, all wrapped up in rhetoric and presented as if it were some profound insight.
Thank you - my thoughts exactly. Sadly, Wired hasn't changed much in the last decade :(
Tim Berners-Lee also invented the HTTP protocol. HTTP 1.0 had the "POST" method and HTPP 1.1 added "PUT". So the read-write capability of the web was there from the beginning. TBL also said the web was meant to be read-write: "I hope I do not have to motive here the fact that the Web in general should be read-write."[1]
If we use Paul Ford's framework that the "web" was meant to be read-only documents, what's the correct intended uses for POST and PUT? The writeback specification was already present at a lower level than the <FORM> element in HTML.
But we have to look at the macro forces beyond HTTP+HTML and consider if a read-only web was realistic. Before 1989 Tim Berners-Lee protocols, older online services like Compuserve and Prodigy already let users do shopping and buy airline tickets. The underlying desire for bi-directional flow of read+write to enable transactions was proven before the www was invented. Therefore, even if TBL himself didn't put write capabilities into the spec, others (maybe Netscape Navigator or Microsoft IE) would have added that capability in as an extension which becomes a defacto standard that everyone adopts. (E.g. Industry adopts MS IE's XMLHttpRequest())
Would the world really want an open platform like HTTP+HTML to have less functionality than the closed commercial services like CompuServe and Prodigy that already had read+write?
[1] https://www.w3.org/DesignIssues/ReadWriteLinkedData.html