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.
QML?
W3C HTML JSON form submission
31–40 of 103 posts
Re: W3C HTML JSON form submission
#32Submitting files with this form encoding is of course going to have the base64 overhead, but otherwise this looks great!
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.
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!
Re: W3C HTML JSON form submission
#33Kind of nice, basically turns form submission into a bare-bones API call.
Which they pretty much already were. The only value I can imagine this adding is a way to encode forms with nested structure.
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.
Re: W3C HTML JSON form submission
#34Kind of nice, basically turns form submission into a bare-bones API call.
Which they pretty much already were. The only value I can imagine this adding is a way to encode forms with nested structure.
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.
Re: W3C HTML JSON form submission
#35Earlier 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'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 too…
it also let's you add a line at the end (most common case) without modifying the previous line.
Re: W3C HTML JSON form submission
#36Why 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!
Re: W3C HTML JSON form submission
#37{ "name": "Bender" , "hind": "Bitable" , "shiny": true } Who puts commas at the start of a continuing line? What good could that possibly do?
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.
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
Re: W3C HTML JSON form submission
#38Earlier 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. 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 too…
it also let's you add a line at the end (most common case) without modifying the previous line.
If you use alphabetically ordered keys (a pretty good practice anyhow), that advantage goes away. If you just develop a habit of adding stuff to the front where semantics do not matter, that advantage goes away.
Re: W3C HTML JSON form submission
#39Earlier quoted context omitted.
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.
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.
XForms has a bigger scope and is connected to XHTML. Two good reasons why this might succeed where XForms failed.
Re: W3C HTML JSON form submission
#40Can we just get rid of HTML and replace it with JSON while we're at it?
JSON rendered with react Js using JSX feels to me like the future of html.
I've heard that before...