Am I the only one who is worried about the fact that this is exponential in size?
W3C HTML JSON form submission
81–90 of 103 posts
Re: W3C HTML JSON form submission
#82It 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.
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.
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.
Re: W3C HTML JSON form submission
#83Submitting files with this form encoding is of course going to have the base64 overhead, but otherwise this looks great!
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.
Re: W3C HTML JSON form submission
#84Wow, 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".
Re: W3C HTML JSON form submission
#85{ "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.
It would also make removing a line a 1-line diff instead of 2. But I still fully agree with the hate.
Re: W3C HTML JSON form submission
#86Wow, 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 how the form fields map to the encoded data for all the encodings you'd want to support.
Re: W3C HTML JSON form submission
#87Earlier quoted context omitted.
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.
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…
Fully agreed. A low(ish)-level, non-JS API to the sea of DOM "primitives" inside blink/gecko/webkit/etc. suitable for targeting in an FFI-like manner by any language is the standard I'd like to see. We don't need 3 languages: it's all there in C++ classes and C structs.
I've been writing a lot of ClojureScript/React lately and with that I only really touch HTML to include CSS and scripts. It's pretty glorious, highly productive, and makes a very strong case for opening up lower levels to allow new paradigms to evolve - with this set-up, HTML and JS only get in the way.
The browser is now (almost) an OS in a VM and, imho, the sooner we start treating it like that the better.
Re: W3C HTML JSON form submission
#88Earlier quoted context omitted.
JSON rendered with react Js using JSX feels to me like the future of html.
I've heard that before... https://en.wikipedia.org/wiki/XSLT
Isn't the Blizzard website largely written in XML and XSLT? I can imagine quite a few scenarios where that can be a good approach.
Re: W3C HTML JSON form submission
#89Am I the only one who is worried about the fact that this is exponential in size? Will generate a request that is ~5MB.
So, y'know, raise it on their issue tracker. :)
Re: W3C HTML JSON form submission
#90Earlier quoted context omitted.
I've heard that before... https://en.wikipedia.org/wiki/XSLT
Isn't the Blizzard website largely written in XML and XSLT? I can imagine quite a few scenarios where that can be a good approach.
An 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.