Derive the step base for an input element as (now) specified.

Source/core/html/forms/InputType.h

 /*
  * Copyright (C) 2010 Google Inc. All rights reserved.
  * Copyright (C) 2011 Apple Inc. All rights reserved.
  * Copyright (C) 2012 Samsung Electronics. All rights reserved.
  *
  * Redistribution and use in source and binary forms, with or without
  * modification, are permitted provided that the following conditions are
  * met:
  *
  *     * Redistributions of source code must retain the above copyright
@@ skipping 178 matching lines @@
     virtual bool isCheckable();
     virtual bool isSteppable() const;
     virtual bool shouldRespectHeightAndWidthAttributes();
     virtual bool supportsPlaceholder() const;
     virtual bool supportsReadOnly() const;
     virtual void updatePlaceholderText();
     virtual String defaultToolTip() const;
     virtual Decimal findClosestTickMarkValue(const Decimal&);
     virtual void handleDOMActivateEvent(Event*);
 
-    // Parses the specified string for the type, and return
+    // Parses the first string argument for the input type, and return
     // the Decimal value for the parsing result if the parsing
-    // succeeds; Returns defaultValue otherwise. This function can
-    // return NaN or Infinity only if defaultValue is NaN or Infinity.
-    virtual Decimal parseToNumber(const String&, const Decimal& defaultValue) const;
+    // succeeds. If not, that parsing is attempted for the second
+    // argument. If that also fails, it returns defaultValue. This
+    // function can return NaN or Infinity only if defaultValue is NaN
+    // or Infinity.
+    virtual Decimal parseToNumber(const String&, const String&, const Decimal& defaultValue) const;

[sof, 2013/11/22 12:50:49]

FYI - I went back & forth a bit on whether or not to extend parseToNumber() like
this -- the alternative being to handle it in the createStepRange() methods for
the input types that have a step base. They were in the majority, hence I opted
for this, but could easily be convinced to address it differently.

[tkent, 2013/11/24 22:34:23]

I don't think adding another argument to parseToNumber is reasonable.
The new behavior looks out of scope of parseToNumber.

We should handle value attribute fallback in each of createStepRange, and we may
have an additional helper function.

[yosin_UTC9, 2013/11/25 01:26:41]

Agree with tkent@. It is confusing having alternative and default.
nit: Please put parameter name for const String&.

[sof, 2013/11/26 17:59:05]

Thanks, added a helper InputType::findStepBase(const Decimal&) instead &
reverted changes to parseToNumber().

(I did not give parseToNumber()'s first argument a name, however. Not sure there
is one that conveys considerable meaning.)

 
     // Parses the specified string for this InputType, and returns true if it
     // is successfully parsed. An instance pointed by the DateComponents*
     // parameter will have parsed values and be modified even if the parsing
     // fails. The DateComponents* parameter may be 0.
     virtual bool parseToDateComponents(const String&, DateComponents*) const;
 
     // Create a string representation of the specified Decimal value for the
     // input type. If NaN or Infinity is specified, this returns an empty
     // string. This should not be called for types without valueAsNumber.
@@ skipping 23 matching lines @@
     Decimal parseToNumberOrNaN(const String&) const;
     void countUsageIfVisible(UseCounter::Feature) const;
 
 private:
     // Helper for stepUp()/stepDown(). Adds step value * count to the current value.
     void applyStep(int count, AnyStepHandling, TextFieldEventBehavior, ExceptionState&);
 };
 
 } // namespace WebCore
 #endif