Michael added a comment.

  <input type="number" />
  -----------------------
  
  Inputs with `type="number"` do allow and work correctly with the "scientific" 
notation  like `1e2` (=100). However, while they allow explicitly signed 
numbers like `-3` or `+5`, trying to indicate a precision like `10+-5` is _not_ 
possible, even though it can technically entered. See 
https://jsfiddle.net/dfv1Lrnu/1/ for a sandbox to play around with this.
  
  Seeing `<input type="number" />` seem insufficient, I looked at two other 
component libraries:
  
  other libraries
  ---------------
  
  vuetify
  -------
  
  has only generic v-input <https://vuetifyjs.com/en/components/inputs/> 
intended to be extended and a higher-level v-text-field 
<https://vuetifyjs.com/en/components/text-fields/>.
  
  `v-input` has a "rules <https://vuetifyjs.com/en/api/v-input/#readonly>" prop 
to pass validating functions that can return `true`,`false` or a error message.
  `v-input` does _not_ have a type field as far as I can tell.
  --> all validation is left to the application and has to be done manually
  
  material-ui
  -----------
  
  has also only a generic input component <https://material-ui.com/api/input/>, 
but has transformed some <input> html-attributes into props, including `type`.
  
  Recommendation
  --------------
  
  **Let's //not// make a dedicated NumberInput at all.**
  
  Recommendation for the input in the Limit component
  ---------------------------------------------------
  
  **Use a normal TextInput, add validation in application.**
  
  Recommendation for the input in the QuantitySelector
  ----------------------------------------------------
  
  **Use a normal TextInput. (or reuse Input component directly)**
  
  However, validation can //either// be left entirely up to consuming 
application //or// it can be done inside the QuantitySelector component with a 
overridable validation method and a required prop for the message if input is 
invalid.
  
  PRO validation in application:
  ------------------------------
  
  - the way vuetify does it
  - most flexible
  - component can be used for other uses/datatypes consisting of an input and a 
lookup
  - maybe query selector doesn't want to allow 1000+-20 syntax?
  - would allow for validation to happen in the backend
  
  CON validation in application:
  ------------------------------
  
  - we maybe have to write the same validation in multiple places
  
  
  
  PRO validation in QuantitySelector component:
  ---------------------------------------------
  
  - it is already a Wikidata/Wikibase-specific component
  
  CON validation in QuantitySelector component
  --------------------------------------------
  
  - makes the component weirdly specific
  - adds behavior that requires specific copy, but no copy
  
  
  
  Conclusion
  ----------
  
  **It is recommended to do all the validation always in the consuming 
application. The design system can and should offer recommendations for how the 
validation should look like.**
  
  Down the road and not connected to the current components, it might be worth 
exploring to either add more props to the TextInput component or to allow 
setting attributes on the `<input>` directly. In particular, the autocomplete 
<https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input#htmlattrdefautocomplete>
 seems worth supporting.
  
  It is also worth emphasizing, that this investigation is only for the 
`type="number"`. It might still be worth looking into things like `type="url"` 
and `type="email"` to make use of the specialized keyboards on mobile devices.

TASK DETAIL
  https://phabricator.wikimedia.org/T273795

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Michael
Cc: ItamarWMDE, Aklapper, Sarai-WMDE, Akuckartz, Nandana, Lahi, Gq86, 
GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, 
Volker_E, Wikidata-bugs, aude, Lydia_Pintscher, Mbch331
_______________________________________________
Wikidata-bugs mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

Reply via email to