Intent to Prototype: input.rawValue

[Joey Arhar]

Contact emails

jar...@chromium.org

Explainer

https://docs.google.com/document/d/1UrwLarU-o_-22OMddCH-fu5YJwmIKHwby3SR3_jQ9YM

Summary

This feature is a read-only property for <input> elements presently called "rawValue" (naming currently in discussion). input.rawValue returns the actual text inside of textual input elements, as opposed to the sanitized value returned in the value property. For example, if a user enters "1234ee" into an <input type=number>, the rawValue property would return "1234ee," as opposed to the value property which returns an empty string.

Motivation

Currently, there is no way to retrieve the actual text a user has entered into certain types of input elements due to the sanitization that occurs when accessing the value property, particularly on the number and email input types. Without the ability to do this, virtual DOM framework authors are forced to guess what text the user entered to avoid clearing the text or selection when assigning to the value property. It doesn't work perfectly, and they have to chase down bugs by adding more and more logic on top of input elements.

Risks

Interoperability and Compatibility

There are no specs, implementations, or tests of this feature yet, and there have not been any comments from other browsers yet.

This feature will be detectable by looking for the presence of the rawValue property on input elements which support it.

I have not reached out to other browsers directly yet, but I made a spec issue to drive more discussion here: https://github.com/whatwg/html/issues/5257

Edge: No signals

Firefox: No signals

Safari: No signals

Web / Framework developers: React developers are supportive, web developers are interested in the problem this could solve as shown in the bug links in the explainer

Ergonomics

This new property will be similar to the .value property, and for certain input types it would return the same value.

I don't have any performance concerns with this new API.

Activation

It should be relatively easy for developers to take advantage of this feature.

There does not appear to be a way to polyfill this feature.

Documentation on MDN would be good, but I don't think that significant outreach would be needed.

I don't think libraries will be needed to be built on top of rawValue, but usage in frameworks is important.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes

Link to entry on the feature dashboard

https://www.chromestatus.com/feature/5986951683375104

Requesting approval to ship?

No. I will add this feature as a prototype behind a flag.

[PhistucK]

> For example, if a user enters "1234ee" into an <input type=number>, the rawValue property would return "1234ee," as opposed to the value property which returns an empty string.

Why does the browser let you type the second "e"? Is that valid anyhow (can there be more than one "e"?)?

(And if there is only one "e" and nothing after it, I expect the browser to ignore it and return the numeric value)

For e-mail, value seems to return the invalid value.

So I am not sure whether this intent is needed for specific cases you mentioned... However, it may solve another problem with sanitization - https://github.com/whatwg/html/issues/1467.

☆PhistucK

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK6btw%2BTYPMccFxf3t_92Znhe4d94J5HZuwDGwe1GpKv5zXGmA%40mail.gmail.com.

[Joey Arhar]

<input type=email> will sanitize the user input before returning it in .value in a couple different ways:

• punycoding domain names: "user@ß.com" => "us...@ss.com"
• trimming leading whitespace: "  us...@example.com" => "us...@example.com"
• trimming trailing whitespace: "us...@example.com  " => "us...@example.com"

Unlike type=number, type=email does return values which don't pass validation in the .value property as you pointed out. However, this sanitization that occurs in email inputs still causes bugs in frameworks like the ones I linked in the explainer.

"1234ee" is probably not the best example, since as you pointed out it doesn't really make a lot of sense. However, here are some more examples with <input type=number>, some of which are more typical:

• trailing periods are trimmed: "1234." => "1234"
• singular "e" about to be used for scientific notation causes value to return nothing: "1234e" => ""
• leading "-" about to be used to input a negative number causes value to return nothing: "-" => ""
• leading or trailing "+" is always trimmed: "+1234" => "1234"
• trailing "-" is always trimmed: "1234-" => "1234"

I'm interested in learning how rawValue could be used for the textarea maxlength interop issue you linked. I don't see exactly how this could solve it, could you elaborate?

[PhistucK]

Not exactly solve it, but it can provide the, well, raw value, rather than the sanitized one for frameworks that deal with servers. Maybe it has nothing to do with it after all.

I think most of the number examples are (browser or specification) bugs, to be honest.

I think the browser should not allow that trailing minus. Looks like the input prevention is simply far too simplistic and that is a bug.

The leading plus and single minus output makes sense, because this is not the goal of that input type (unless I misunderstand).

Coming back to your goal, though, virtual DOM frameworks, yeah, I get it (sorry for missing this earlier).

Looking at it differently, though, maybe the frameworks can be doing their work differently? I have no suggestions because I do not know the implementations and the rules they had to add, but maybe browsers can help with their expertise there.

Since date and time inputs will not be solved this way (due to fingerprinting issues. By the way, are number inputs not prone to that? Commas as decimal points and similar?), the frameworks will have to have rules for those anyway... So maybe there is another way to keep things private as well as lessen the work for frameworks?

Maybe add input.valueType (in addition to input.type) and frameworks will use that instead of type and this way they could get the raw input (because the type will be text) and the browser will treat the field as its valueType? Just thinking out loud...

☆PhistucK

[Mounir Lamouri]

On Fri, 7 Feb 2020 at 15:41, PhistucK <phis...@gmail.com> wrote:

Maybe add input.valueType (in addition to input.type) and frameworks will use that instead of type and this way they could get the raw input (because the type will be text) and the browser will treat the field as its valueType? Just thinking out loud...

Isn't this very similar to inputMode? https://html.spec.whatwg.org/multipage/interaction.html#input-modalities:-the-inputmode-attribute

 

On Thu, Feb 6, 2020 at 1:22 AM Joey Arhar <jar...@chromium.org> wrote:

Motivation

Currently, there is no way to retrieve the actual text a user has entered into certain types of input elements due to the sanitization that occurs when accessing the value property, particularly on the number and email input types. Without the ability to do this, virtual DOM framework authors are forced to guess what text the user entered to avoid clearing the text or selection when assigning to the value property. It doesn't work perfectly, and they have to chase down bugs by adding more and more logic on top of input elements.

Do you have examples of this? How are these frameworks making the guesses? Do they use the input event?

 

-- Mounir

[Joey Arhar]

> Do you have examples of this? How are these frameworks making the guesses? Do they use the input event?

Here is a manual test site react set up with an older version of react, which shows some crippling issues with number inputs when you follow the instructions (there's also an entry for email input issues in the drop down): https://react-dom-fixtures.surge.sh/number-inputs?version=15.0.0

They have since added more logic to prevent as many issues, but they also said that having input.rawValue would prevent more issues and simplify their code. I also imagine that developers must have moved away from native form controls while these bugs persisted.

As for what exactly react is doing, I found these lines of code relevant but I don't know exactly what events they are listening to and exactly how the past issues were addressed. I could ask my react contact if you're interested.