W3C HTML JSON form submission

Post by skratlo » Thu, Nov 27, 2014, 5:42 PM UTC

tomchristie wrote: post #86

skratlo wrote: post #84

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…

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 h…

Post by griffindy » Thu, Nov 27, 2014, 5:58 PM UTC

stephenr wrote: post #76

ajanuary wrote: post #51

Earlier quoted context omitted.

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…

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)?

Post by byuu » Thu, Nov 27, 2014, 6:16 PM UTC

JetSpiegel wrote: post #79

Xophmeister wrote: post #71

Earlier quoted context omitted.

Nodes have multiple children. In this case, you can split the 's children into three: a "text node"; a 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.

This has to be pre-processed somehow, if people don't like writing HTML by hand, consider writing that.

    

      This is
      bold
      text.
    

    html
      body
        p: "This is [/italic/] text."
        p: "This is [[google.com => a hyperlink.]]"

Post by diroussel » Thu, Nov 27, 2014, 7:04 PM UTC

nkuttler wrote: post #54

pielud wrote: post #24

Earlier quoted context omitted.

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.

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

Post by icebraining » Thu, Nov 27, 2014, 7:13 PM UTC

chronial wrote: post #81

Am I the only one who is worried about the fact that this is exponential in size? Will generate a request that is ~5MB.