Post

So, today I built `<calc-input>`. It’s a custom input element that accepts mathematical formulas — such as 2 + 3 or (2 + 3) * 4 — and automatically toggles between showing the formula on focus and the calculated result on blur. → brm.us/calc-input

Bramus@bram.us

Oh no. I managed to nerd snipe myself into Yet Another Side Project™ … again. Noooooo. #TooManyIdeas

8 reposts63 likes

The Light DOM approach keeps native form submission, but the formula/result swap seems worth an accessibility check. Are both inputs consistently labelled, and can screen-reader users review the calculated value without losing the original formula context?

Oh, that’s great feedback! Let me try and think on how to fix it properly …

I had to implement this at work a couple of years ago, it was actually quite fun to build That one also had a *totally unnecessary* small floating numpad showing up below the input field on focus just to highlight that it accepted formulas lol

No. The input does not accept the = sign. The whole expression you enter is evaluated.

My initial expectation was that = at the start would opt into evaluation, whereas = at the end would either replace the formula by its result or work as a comparison operator.

The opt-in is using the component. If you don’t want the result to be evaluated, use a regular text (or number) input.

I wonder if this would look nicer using something like what Apple Notes does. So that the calculation is always shown but the result is rendered after. Downside would be that the form `value` wouldn't work (could use a separate hidden input)? And maybe OpaqueRange to highlight the result?

The control deliberately does not accept = symbols and is focused on only accepting the formula. It already uses a mutliple inputs behind the scenes to switch between formula and result. That said, perhaps there could a be live-eval going on that anchors the result to the end of the text somehow.