Input helper does not properly handle numbers in exponential/scientific notation

[jacobq]

This works:

{{input type='number' min=0 max=100 step=0.01}}

but this (which I think should be equivalent) doesn't:

{{input type='number' min=0e0 max=1e2 step=1e-2}}

although the HTML version does (tested in Chrome 64)

<input type="number" min="0e0" max="1e2" step="1e-2">

Work-around: quoting the parameters seems to cause them to be interpreted correctly, so I'm not really sure if this is an issue with {{input}} or HTMLbars or my understanding of syntax of what.

{{input type='number' min='0e0' max='1e2' step='1e-2'}}

Note that ['0e0', '1e+2', '1e-2'].map(parseFloat) returns [0, 100, 0.01]

Here is a twiddle demonstrating the problem: https://ember-twiddle.com/84461a3ca5397794b6df2f75c4999c80

[rwjblue]

Hmm, the two examples given are actually quite different.

<input type="number" min="0e0" max="1e2" step="1e-2">

Sets the min,max, and step to strings (even if they were not quoted, they would be treated as strings by the HTML tokenizer in the browser as all attributes are strings).

It seems that the way parsing is done in this example {{anything-here someArg=1e-2}} the 1e-2 bit is treated like a path expression (and therefore evaluates to undefined). This does seem odd to me, but doesn't really seem like a big (more of a parser quirk). @mmun may have more thoughts on that though.

[jacobq]

@rwjblue Thanks for taking a look at this issue. If it's not a bug then I guess my question becomes one of documentation, i.e. Where should I have read that I need to convert numeric literals to string literals in order to use them in these templates? If I bind to a numeric variable instead (e.g. set min: 0 on controller and use {{... min=min ...}}) it works fine, so I would have expected it to work the same with a constant number. Is the min controller property that I just described getting converted to a string automatically as part of the process?

[yininge]

I think we should label this as "documentation" or "needs team discussion". It does seem strange that using {{... min=min ...}} works but {{... min=0e0 ...}} does not work. It's worth document to avoid confusion about this behavior.

[pixelhandler]

@emberjs/learning-team-managers what do you think about adding specific documentation for exponential/scientific notation on the template helpers guides?

[acorncom]

@pixelhandler I think adding something about it to the API docs for the input helper might be reasonable. Given the relative rarity for folks to need this, recommending the use of a regular <input> is probably the best route to take. It's probably better to add it to api docs than in the full-on guides ...

[rwjblue]

Hmm, Ember.TextField (which is used by {{input) specifically states that min / max are strings. TBH, I don't think there is a reasonable place to document this that would have been very clear to @jacobq (or others hitting this issue). I believe the right fix is to just continue pushing forward with alternate component base classes (e.g. sparkles-component) which intentionally leverage outer HTML semantics. This would push folks down the path that actually does work (using <input min="...">) by default.

Thank you to everyone for their help on this and I do apologize for not having a resolution that has better "feels", but I am going to go ahead and close this as a (very polite) "won't fix"...

[jacobq]

Thanks, all, for your consideration. I understand your reasoning in not addressing this, though I often wonder what I have done to upset the gods such that I seem to be always doing things that are "rare" and stepping on landmines that don't bother anyone else.

Perhaps someone would be willing to write a rule for the template linter that would warn against this? e.g.

{{input min=1 max="1e6" value=foo}}{{! OK }}
{{input min=1.23 max=1e6 value=bar}}{{! should fail 'no-non-integer-numeric-literals' }}

[rwjblue]

Sounds like a great linting rule!