Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

W3C HTML JSON form submission

w3.org

Post reply on HN
Print view View original

71–80 of 103 posts

Re: W3C HTML JSON form submission

#71

Post by Xophmeister »

byuu wrote: post #55
Patrick_Devine wrote: post #9

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

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: This is bold text. "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…

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.

Re: W3C HTML JSON form submission

#72

Post by stephenr »

byuu wrote: post #65
joesb wrote: post #60

Earlier quoted context omitted.

What's the problem with that? If it's deeply nested, then it's deeply nested, no matter what.

It's pedantic, but it's a tad clunky now: I'd use something like "wow/such/deep[3]/much/power/!" to differentiate child nodes from array indexes, and also strongly advise against a node named "!" on principle. Of course then you'd say "but I want '/' in my node name!", and then you get to bikeshed an escape sequence, but you'd need that anyway for a node name with '[' or ']' in it. However, what they've done is worka…

square brackets are a reasonably common way to access data in an hash-like object. both Javascript (objects) and PHP (associative arrays) use/allow square brackets for this.

Re: W3C HTML JSON form submission

#74

Post by billpg »

tomchristie wrote: post #67
billpg wrote: post #63

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.

JSON Pointer isn't quite the same thing.

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.

Re: W3C HTML JSON form submission

#76

Post by stephenr »

ajanuary wrote: post #51
rspeer wrote: post #42

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…

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

Re: W3C HTML JSON form submission

#77

Post by tomchristie »

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

Sure, yes. In Python land for example Django and Flask both present the request parameters in a dictionary-like data structure that supports lookup of the complete list of values passed for a given name. Regular lookups will give you just a single value, but they also present an interface to get the complete list.

Re: W3C HTML JSON form submission

#78

Post by JetSpiegel »

kijin wrote: post #36

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

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.

Re: W3C HTML JSON form submission

#79

Post by JetSpiegel »

Xophmeister wrote: post #71
byuu wrote: post #55

Earlier quoted context omitted.

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: This is bold text. "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…

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.
Post reply on HN