8 ms·
W3C HTML JSON form submission
- tootie 12y agoThey're still working on XForms after 10 years http://www.w3.org/MarkUp/Forms/ http://www.w3.org/MarkUp/Forms/
- matthewmacleod 12y agoIsn't that kind of like saying "They're still working on HTML after 23 years"? Technically you're right, but version 1.1 of XForms was completed and published over 5 years ago. That said, XForms is dead AFAIK, and that's not a bad thing.
- gsnedders 12y agoWork on XForms 2.0 is ongoing! Odds of it ever getting implemented in a browser are slim, however.
- AlainCouthures 12y agoMy XForms implementation (XSLTForms) works in a browser using XSLT and Javascript. The next version will even just require Javascript!
- tootie 12y agoYeah, my point was more along the lines of they've been working for 10 years and gotten near zero adoption. Not saying it will fail again for sure, but if this had value, XForms would have found it. URL-encoded POST data works just fine.
- jkrems 12y agoXForms has a bigger scope and is connected to XHTML. Two good reasons why this might succeed where XForms failed.
- woutervdb 12y ago> wow[such][deep][3][much][power][!] And there goes my interest for this submission. Don't use overused memes in a submission. Liking the idea though.
- Donzo 12y agoI enjoyed this. I also liked the Bender reference. It reminded me of that show that makes me laugh on Netflix. It also illustrated the point that he was trying to make. I prefer warm examples, rather than ones using book titles.
- edwinvdgraaf 12y agoGuessing that it's interesting when using an uniform endpoint for both forms and js-driven requests.
- techtalsky 12y agoKind of nice, basically turns form submission into a bare-bones API call.
- tootie 12y agoWhich they pretty much already were. The only value I can imagine this adding is a way to encode forms with nested structure.
- hayksaakian 12y agoThe changes they make solve the problem of corner cases submitting weird input to an API that expects only JSON In 2014, I think this is a good idea. It also solves the issues with ambiguous syntax surrounding arrays of values.
- hayksaakian 12y agoThe changes they make solve the problem of corner cases submitting weird input to an API that expects only JSON In 2014, I think this is a good idea. It also solves the issues with ambiguous syntax surrounding arrays of values.
- bkardell 12y agoIn fairness, you have to look at how standards get somewhere - this is an editor's draft which is a starting point of an idea rather than a done deal. Don't be surprised if the final product winds up being significantly different than this - even better, get involved in the conversation to make it what we need. That's not to pour cold water on it: It's good as it is, but there are changes which potentially help explain the magic of participating in form encoding and submission which may be better and allow more adaptation and experimentation over time.
- stu_k 12y agoSubmitting files with this form encoding is of course going to have the base64 overhead, but otherwise this looks great!
- treve 12y agoYea this makes me wish there was a better way to deal with this. JSON is popular because it's simple, but as a result sucks for a bunch of use-cases.
- tonyarkles 12y agoI'm mobile so don't have a good way to just test this myself... Any idea how good/bad base64+gzip is (ie gzipping the json before submitting it)? If it's within a few percent then this probably isn't a bad solution!
- dnet 12y agoThe browser doesn't gzip _requests_ by itself, only the server does so with the _response_ if the user-agent (including browsers) states that it supports such content encoding. Of course you can implement gzip in JavaScript, but if you do that, you can already mangle the request and send the file to the server without Base64 encoding.
- icebraining 12y agoIn fact, HTML already has a solution for that in the form of multipart/form-data. Instead of encoding the files directly inside JSON, you could add them as extra parts of the MIME message, and just have a reference in the JSON value (as in email, which uses a "cid:<part-identifier>" URI to inline images as such, as described in RFC2392). You'd still need special support on the server, though.
- Silhouette 12y agoSubmitting files with this form encoding is of course going to have the base64 overhead HTTP connections typically use compression with any modern browser and server, so there is likely to be little overhead in practice.
- Patrick_Devine 12y agoCan we just get rid of HTML and replace it with JSON while we're at it?
- mcintyre1994 12y agoJSON rendered with react Js using JSX feels to me like the future of html.
- scrollaway 12y agoI've heard that before... https://en.wikipedia.org/wiki/XSLT https://en.wikipedia.org/wiki/XSLT
- Argorak 12y agoIsn't the Blizzard website largely written in XML and XSLT? I can imagine quite a few scenarios where that can be a good approach.
- mcintyre1994 12y agoAn interesting example I came across is documenting an xml schema by converting it to xhtml. I think it goes without saying that Javascript and JSON make react a lot friendlier though.
- scrollaway 12y agoThe WoW Armory website used to be written in XSLT on top of a horrendeous java stack. It's commonly referred to as the badmory and was slow as all hells. It had a pure-html fallback (rendered serverside into html) for unsupported browsers. It's one of the worst pieces of web I've ever seen... and I've seen some stuff. It's no longer using all this, of course. They hired the guys from wowhead.com and had them redo the whole thing in a saner stack.
- byuu 12y agoI don't know if there's a proper name for this ability, but neither JSON nor YAML allow you to embed child tree nodes inside of node values. This ability requires named end tags. Example: <p>This is <b>bold</b> text.</p> "p": "This is ... uh ... nevermind." You could make a compelling argument that you shouldn't do this (separate block level and inline elements into separate encodings), but remember that even the relatively minor HTML->XHTML movement to put a bit of sanity into single-use tags like <br> -> <br/> failed miserably.
- lorddoig 12y agoIt amazes me that we're now at the point of standardizing sticking array references inside strings and yet we're still not having a serious discussion about what comes after HTML.
- andrewstuart2 12y agoWhat's wrong with a human-readable serialization format?
- lorddoig 12y agoNothing - I was talking about this: <input name='kids[1]' value='Thelma'> <input name='kids[0]' value='Ashley'>
- andrewstuart2 12y agoWhoa. I missed that. Probably by clicking the link to the serialization algorithm. That's bad. Really, really bad.
- libria 12y agoWhat structure are we suggesting? This?: <inputgroup name='kids'> <input value='Thelma'> <input value='Ashley'> </inputgroup>
- arcatek 12y agoI guess that it's because at first, it was assumed that it was one of the servers jobs to parse such structures based on their names. Since these same servers failed to establish a consensus (Django using "a=1&a=2" as array, whilst php uses "a[]=1&a[]=1", for example), someone has to start ...
- chc 12y agoIt amazes me that you think we could have a serious discussion about what comes after HTML when essentially nobody is seriously considering replacing HTML. HTML is what it is, nothing else is what HTML is, and HTML is going to be around a good long while.
- mnarayan01 12y agoThe JSON-based file upload would be nice (AFAIK there's not great way to do this ATM, but I haven't looked in over a year). The rest seems pretty weak-tea though. I can see multiple issues with more defined type (e.g. numeric rather than string values, null rather than blank string), but without dealing with that stuff, this seems of extremely limited utility.
- alex_duf 12y agoIt's nice for small files but base64 really is inefficient. I think it is still used in mails, but really, you should use it only when you control all the usages that will be done with it.
- hughes 12y ago{ "name": "Bender" , "hind": "Bitable" , "shiny": true } Who puts commas at the start of a continuing line? What good could that possibly do?
- bkardell 12y agoSend a pull - github for the win! http://darobin.github.io/formic/specs/json/ http://darobin.github.io/formic/specs/json/
- pielud 12y agoIt lets you comment out a line without having to remove the trailing comma from the previous line. That'd be useful if JSON had comments. I've seen people do this in the SELECT portion of SQL queries too. Personally, I hate this.
- hughes 12y agoTrue about the comment. That's why I like the trailing comma style in pep8[1], which enables both commented out array elements and smaller, more meaningful diffs when making additions or deletions. If only trailing commas were valid JSON! [1] https://dev.launchpad.net/PythonStyleGuide https://dev.launchpad.net/PythonStyleGuide
- dragonwriter 12y ago> It lets you comment out a line without having to remove the trailing comma from the previous line. That'd be useful if JSON had comments. It also lets you remove the line (for the same reason that you can comment it out) without modifying other lines. This is somewhat convenient if the file is one that you are going to manually edit (and even more useful if it is going to be the subject of line-oriented diffing tools, since the only changed lines will be the ones with meaningful changes.) I'd agree that its less readable, though.
- lucio 12y agoit also let's you add a line at the end (most common case) without modifying the previous line.
- kijin 12y agoWhy such an emphasis on "losing no information" when the form is obviously malformed? You need only to look at the crazy ways in which MySQL mangles data to realize that silently "correcting" invalid input is not the way to go. The web has suffered enough of that bullshit, we seriously don't need another. Example 7 (mixing scalar and array types) gives me shudders. Example 10 (mismatched braces) seems to have a reasonable fallback behavior, though I'd prefer dropping the malformed field altogether. If the form is obviously malformed, transmission should fail, and it should fail as loudly and catastrophically as possible, so that the developer is forced to correct the mistake before the code in question ever leaves the dev box. Preferably, the form shouldn't even work if any part of it is malformed. If we're too timid to do that, at least we should leave out malformed fields instead of silently shuffling them around. Otherwise we'll end up with frameworks that check three different places and return the closest match, leaving the developer blissfully ignorant of his error. While we're at it, we also need strict limits on valid paths (e.g. no mismatched braces, no braces inside braces) and nesting depth (most frameworks already enforce some sort of limit there), and what to do when such limits are violated. Again, the default should be a loud warning and obvious failure, not silent mangling to make the data fit. This is supposed to be a new standard, there's no backward-compatibility baggage to carry. So let's make this as clean and unambiguous as possible!
- JetSpiegel 12y agoThat's not the Web way. The Web is the lowest common denominator, all that talk of "correctness" goes over the head of most Web Developers.
- rspeer 12y agoLet me say first of all that I'm glad they're working on standardizing this. When making REST APIs, I find HTML form scaffolds incredibly useful, but it means that you probably have to accept both JSON (because JSON is reasonable) and occasional form-encoding (because forms), leading to subtle incompatibilities. Or you have to disregard HTML and turn your forms into JavaScript things that submit JSON. Either way, the current state is ugly. Here's the part that I don't particularly like, speaking of subtle incompatibilities: EXAMPLE 2: Multiple Values <form enctype='application/json'> <input type='number' name='bottle-on-wall' value='1'> <input type='number' name='bottle-on-wall' value='2'> <input type='number' name='bottle-on-wall' value='3'> </form> // produces { "bottle-on-wall": [1, 2, 3] } I've seen this ugly pattern before in things that map XML to JSON. Values spontaneously convert to lists when you have more than one of them. Here come some easily overlooked type errors. I don't know of any common patterns for working with "a thing or a list of things" in JSON; that kind of type mixing is the thing you hope to get away from by defining a good API. But all code that handles HTML JSON is going to have to deal with these maybe-list-maybe-not values, in a repetitive and boilerplatey way. I hope that a standard such as this will eventually be adopted by real-life frameworks such as Django REST Framework, but I also hope that they just reject the possibility of multiple fields with the same name.
- IgorPartola 12y agoPHP handles this by having lists like this by requiring you to use an I put name like "bottle-on-a-wall[]". The brackets indicate that it should be a list. I don't hate this convention...
- andyfleming 12y agoYeah. I feel like the bracket syntax is better. The other example above isn't explicit enough, IMO.
- hayksaakian 12y agothe only problem with the bracket syntax is when it comes to nested things <form enctype='application/json'> <input name='wow[such][deep][3][much][power][!]' value='Amaze'> </form> // produces { "wow": { "such": { "deep": [ null , null , null , { "much": { "power": { "!": "Amaze" } } } ] } } }
- luikore 12y agoI don't agree with Example 9, we should use data uri scheme for file content "files": [{ "name": "dahut.txt", "src": "data:text/plain;base64,REFBQUFBQUFIVVVVVVVVVVVVVCEhIQo=" }] http://en.wikipedia.org/wiki/Data_URI_scheme http://en.wikipedia.org/wiki/Data_URI_scheme
- theandrewbailey 12y ago1. Other form encoding types have discrete MIME type fields. 2. While data URIs are awesome, it forces you to process that URI in some way (parse, regex, whatever) just to get the MIME type. Also, this forces 13 bytes of redundancy every time.
- jimmcslim 12y agoI'm not sure whether to be heartened or concerned that the W3C is referencing the doge meme in its specifications... see Example 6.
- jl6 12y agoConcerned. Memes are in-group signalling one notch above the crudest kind such as football chants, a few notches below the more sophisticated kind like quoting Shakespeare, but all ultimately with the potential to exclude and confuse - which is definitely the opposite of what a technical spec should be trying to do.
- icebraining 12y agoI don't see why would this exclude or confuse. It's essentially an in-joke, and shouldn't affect anyone reading the spec who is unaware of the meme. I'm not a fan, but I don't think we should make it out to be more than it really is.
- tomchristie 12y agoSeems pretty decent. Also neat that the nesting style could be repurposed to support nested structures in regular form-encoded HTML forms. Main limitation on actually being able to use this is that `GET` and `POST` continue to be the only supported methods in browser form submissions right now, so eg. you wouldn't be able to make JSON `PUT` requests with this style anytime soon. Might be that adoption of this would swing the consensus on supporting other HTTP methods in HTML forms.
- billpg 12y agoA new standard for referencing a point in a JSON object? I wonder if they considered RFC 6901 and rejected it. I personally prefer this new square bracket notation, but being a standard already gets more points.
- tomchristie 12y agoJSON Pointer isn't quite the same thing.
- billpg 12y agoI humbly disagree. JSON Pointer is a syntax for specifying a location in a JSON object. Multiple form items with JSON pointer strings as names would map to the equivalent of a number of add operations in a PATCH call that start with an empty object.
- deleted 12y ago[deleted]
- jdp 12y agoThe latest release of my jarg[0] utility supports the HTML JSON form syntax. Writing out JSON at the command line is tedious, this makes it a little nicer. The examples from the draft are compatible with jarg: $ jarg wow[such][deep][3][much][power][!]=Amaze {"wow": {"such": {"deep": [null, null, null, {"much": {"power": {"!": "Amaze"}}}]}}} [0]: http://jdp.github.io/jarg/ http://jdp.github.io/jarg/
- pmontra 12y agoA discussion about the implementation of the spec in jquery. It started on June 21 https://github.com/macek/jquery-serialize-object/issues/24 https://github.com/macek/jquery-serialize-object/issues/24
- chronial 12y agoAm I the only one who is worried about the fact that this is exponential in size? <input name="field[1000000]"> Will generate a request that is ~5MB.
- tomchristie 12y agoSo, y'know, raise it on their issue tracker. :)
- icebraining 12y agoI don't see why that should be worrying. What's the scenario you're foreseeing?
- skratlo 12y agoWow, W3C at it's best again. Non-modular, non-negotiable, JSON it is, take it or leave it. Well fuck you W3C. Base64 encoded files? Seriously? What if my app workes better with msgpack encoded forms? Or with XML encoded? So you're going to support one particular serialization format, quite a horrible one, but that's subjective and that's the whole point. Every app has different needs and you should spec. out a system that is modular and leaves the choice to the user, even for the price of "complicating things".
- tomchristie 12y agoHow would you deal with rendering arbitrary form encodings in the browser? A proposal adding support for form submission of arbitrary encodings could be valid, but it'd have to just be a single form input with the data included verbatim. This proposal allows regular HTML forms with multiple input elements, but submitting over JSON. I can't see how you could define that for arbitrary encodings without first defining how the form fields map to the encoded data for all the encodings you'd want to support.
- skratlo 12y agoEg: By referencing an encoder function using the standard on* attribute. Could be called onbeforesubmit=encodeMsgpack. This function would take a JS object, generated according to the W3C's JSON form spec, and return a pair of [string, arraybuffer]. String being the MIME content type, and arraybuffer containing the request body.
- icebraining 12y agoIf you're going to run custom JS code, why not simply submit it through JS HTTP requests? What have you gained by this new API?
- apparentlymart 12y agoI think the spec you are looking for is JavaScript.
- homakov 12y agoHow is it solving CSRF JSON problem? http://homakov.blogspot.com/2012/06/x-www-form-urlencoded-vs-json-pros-and.html http://homakov.blogspot.com/2012/06/x-www-form-urlencoded-vs...