W3C HTML JSON form submission

http://www.w3.org/TR/html-json-forms/

by ozcanesen • 12 years ago

262 100 12 years ago

tootie3• 12 years ago

They're still working on XForms after 10 years http://www.w3.org/MarkUp/Forms/

Isn'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• 12 years ago

Work on XForms 2.0 is ongoing! Odds of it ever getting implemented in a browser are slim, however.

tootie3• 12 years ago

Yeah, 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.

woutervdb• 12 years 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• 12 years ago

I 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• 12 years ago

Guessing that it's interesting when using an uniform endpoint for both forms and js-driven requests.

techtalsky• 12 years ago

Kind of nice, basically turns form submission into a bare-bones API call.

tootie3• 12 years ago

Which they pretty much already were. The only value I can imagine this adding is a way to encode forms with nested structure.

hayksaakian2• 12 years ago

The 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.

bkardell2• 12 years ago

In 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• 12 years ago

Submitting files with this form encoding is of course going to have the base64 overhead, but otherwise this looks great!

treve• 12 years ago

Yea 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• 12 years ago

I'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!

icebraining4• 12 years ago

In 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.

Silhouette2• 12 years ago

Submitting 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• 12 years ago

Can we just get rid of HTML and replace it with JSON while we're at it?

mcintyre19942• 12 years ago

JSON rendered with react Js using JSX feels to me like the future of html.

scrollaway2• 12 years ago

I've heard that before...

https://en.wikipedia.org/wiki/XSLT

byuu3• 12 years ago

I 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.

Xophmeister2• 12 years ago

Nodes have multiple children. In this case, you can split the <p>'s children into three: a "text node"; a <b> node; and another text node. You'd end up with something like this:

    {
      p: [
        { text: 'This is' },
        { b: { text: 'bold' }},
        { text: 'text.'}
      ]
    }

Not that I don't agree with you -- my suggestion is pretty messy and doesn't even go into how we'd deal with tag attributes -- but it's doable.

lorddoig3• 12 years ago

It 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.

andrewstuart22• 12 years ago

What's wrong with a human-readable serialization format?

lorddoig3• 12 years ago

Nothing - I was talking about this:

    <input name='kids[1]' value='Thelma'>
    <input name='kids[0]' value='Ashley'>

chc• 12 years ago

It 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.

aplummer• 12 years ago

it'll be like when they replaced paper with the internet...

Silhouette2• 12 years ago

It amazes me that you think we could have a serious discussion about what comes after HTML when essentially nobody is seriously considering replacing HTML.

Of course we are. There are numerous new technologies competing to replace the role we have shoe-horned HTML into playing -- look at all the different templating technologies now in development, for example, and things like Web Components. There are also numerous technologies for marking up semantic content and/or styling such data for presentation.

The only thing that isn't changing right now is that we're still stuck with eventually reducing these alternatives to plain HTML for display in browsers, which is about as good an idea as insisting we reduce all styling to CSS and all programming to JavaScript. It's a historical accident, it's resulted in widespread dependence on tools that are nowhere near fit for the purposes they are now asked to serve, but there is so much momentum in the industry that building tools to accommodate the weaknesses as well as possible is the preferred strategy over completely starting over. See also: Almost everything about programming ever.

nly• 12 years ago

QML?

mnarayan01• 12 years ago

The 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• 12 years ago

It'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.

hughes2• 12 years ago

    {
      "name":   "Bender"
    , "hind":   "Bitable"
    , "shiny":  true
    }

Who puts commas at the start of a continuing line? What good could that possibly do?

bkardell2• 12 years ago

Send a pull - github for the win! http://darobin.github.io/formic/specs/json/

pielud• 12 years 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.

I've seen people do this in the SELECT portion of SQL queries too.

Personally, I hate this.

hughes2• 12 years ago

True 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

dragonwriter• 12 years 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.

dbla• 12 years ago

It also lets you find missing commas more easily.

stevepike• 12 years ago

I think it's great when doing adhoc analysis that only you are ever going to look at, though maybe I just need a better IDE. Another neat / silly trick is to add a truthy condition at the beginning of a where:

   select * 
   from foo
   where 1=1 
     AND bar = 1
     AND baz = 2

That way you can comment out any of your conditions without breaking the syntax.

Pxtl2• 12 years ago

I do it in UPDATES

    UPDATE FOO
    SET BAR = 1
    ,   BAZ = 2
    ,   QUUX = 3

I like it that way. Makes it clear the relationship between the continuing lines and their parents. Just the natural extension of

    WHERE ALICE = 1
    AND BOB =2
    AND CHARLIE = 3

nkuttler• 12 years ago

It lets you comment out a line without having to remove the trailing comma from the previous line

That would only be an advantage above comma at the end on the last line. It really only moves the problem from the last line to the first one. Now you can't comment out the first line without removing a comma...

bobbykjack• 12 years ago

If IE didn't barf on a trailing comma after the last value, we wouldn't have this problem. That's probably the biggest source of all my IE JavaScript bugs. To be fair, I'm not actually sure what the spec says, but the spec might be wrong :-)

jacobr• 12 years ago

It would also make removing a line a 1-line diff instead of 2. But I still fully agree with the hate.

Kiro• 12 years ago

That's how the amazing TJ Holowaychuk declares his imports.

https://github.com/mochajs/mocha/blob/master/lib/suite.js

SixSigma• 12 years ago

Me, it is so much better. The comma is really a particle of the next item, not the previous.

Here's an item there's going to be another one,

Here's an item

, I'm another one

Xophmeister2• 12 years ago

The comma first pattern is pretty common. I've seen it used in JavaScript (as well as JSON), SQL and Haskell; I'm sure there are others.

Some encourage this so you can comment out a line without having to add/remove commas. However, this isn't the case if you want to comment out the first line; so in effect, it just moves the problem from the bottom to the top of the list. Other proponents say it's easier to spot typos (i.e., missing commas). For example:

    var something = {
      foo: 'bar',
      abc: '123'
      quux: null,
      xyz:  456
    };

vs:

    var something = {
      foo: 'bar'
    , abc: '123'
      quux: null
    , xyz:  456
    };

In the second one, it's clearer that there's a comma missing.

Personally, I think it's ugly and, while I'm sure I've erroneously omitted commas before, they're caught by the parser. No example comes immediately to mind where missing a comma can be interpreted as something other than a parse error.

kalleboo• 12 years ago

It makes diffs look nicer when you add and remove items

BasDirks• 12 years ago

You'll see it like this:

    { "name": "Bender"
    , "hind": "Bitable"
    , "shiny": true }

kijin• 12 years ago

Why 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!

JetSpiegel2• 12 years ago

That'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• 12 years ago

Let 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• 12 years ago

PHP 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• 12 years ago

Yeah. I feel like the bracket syntax is better. The other example above isn't explicit enough, IMO.

hayksaakian2• 12 years ago

the 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"
                                }
                            }
                        }
                    ]
                }
            }
        }

ajanuary• 12 years ago

I don't think multiple fields with the same name is designed to be a normal mode of operation. If you actually want an array, use the [] suffix.

But if you have a bug which produces a form with multiple fields with the same name, what should it do? I can think of two strategies: last one wins and the proposal.

Both are probably going to lead to things going wrong in the backend. At least with the proposal you:

A) can detect it with boilerplate that looks for arrays where you expect primitives.

B) figure out what the original data was if you need to try and manually repair it.

I'm sure we'll see lots of bad tutorials suggesting you just use the same field name to make an array though :(

stephenr2• 12 years ago

do any server-side environments currently present an array/array-like structure from request parameters with duplicate names (and specifically without any kind of array indicator, like name[] in php requests for example)?

tomchristie6• 12 years ago

Think that's fair point, yup. Very easy to do unintentionally, and it's non-intuitive that it'll suddenly change the return type.

It's not clear if this style is really necessary. Why not just use the indexed syntax in this case?

I guess it may be the authors intention to mirror form encoded submissions, that would send all of these values to the server.

I'd suggest raising the point on the issue tracker so that it at least gets sufficient design discussion.

https://github.com/darobin/formic/issues

richdougherty• 12 years ago

Well, the safe way would be to mirror the current form spec and treat everything as arrays of strings by default.

    <form enctype='application/json'>
      <input type='text' name='fruit' value='apple'>
      <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>


    {
      "fruit": ["apple"],
      "bottle-on-wall": ["1", "2", "3"]
    }

Then add attributes to explicitly give the structure. Since this is a browser spec we can add attributes. Here's the same form but with some attributes giving the explicit encoding.

    <form enctype='application/json'>
      <input type='text' name='fruit' value='apple' enc='string'>
      <input type='number' name='bottle-on-wall' value='1' enc='array/number'>
      <input type='number' name='bottle-on-wall' value='2' enc='array/number'>
      <input type='number' name='bottle-on-wall' value='3' enc='array/number'>
    </form>

    {
      "fruit": "apple",
      "bottle-on-wall": [1, 2, 3]
    }

Dynamically varying JSON structures by form names and number of form elements is definitely going to be a source of bugs and security problems.

luikore• 12 years ago

I 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

theandrewbailey• 12 years ago

1. 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• 12 years ago

I'm not sure whether to be heartened or concerned that the W3C is referencing the doge meme in its specifications... see Example 6.

jl6• 12 years ago

Concerned. 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.

icebraining4• 12 years ago

I 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.

tomchristie6• 12 years ago

Seems 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.

billpg2• 12 years ago

A 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.

tomchristie6• 12 years ago

JSON Pointer isn't quite the same thing.

billpg2• 12 years ago

I 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.

jdp• 12 years ago

The 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/

pmontra• 12 years ago

A discussion about the implementation of the spec in jquery. It started on June 21

https://github.com/macek/jquery-serialize-object/issues/24

chronial• 12 years ago

Am 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.

tomchristie6• 12 years ago

So, y'know, raise it on their issue tracker. :)

icebraining4• 12 years ago

I don't see why that should be worrying. What's the scenario you're foreseeing?

skratlo2• 12 years ago

Wow, 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".

tomchristie6• 12 years ago

How 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.

skratlo2• 12 years ago

Eg: 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.

apparentlymart• 12 years ago

I think the spec you are looking for is JavaScript.

homakov• 12 years ago

How is it solving CSRF JSON problem? http://homakov.blogspot.com/2012/06/x-www-form-urlencoded-vs...

W3C HTML JSON form submission

Related Stories