[Bug 8436] "granularity that is expected (and required) of the value, by limiting the allowed values" -- granularity requirments may often be different for validation versus usability/ui-control purposes. There should be a 'step' for possible GUI controls and an oth

http://www.w3.org/Bugs/Public/show_bug.cgi?id=8436


x.a <whatwg2k101.d.xenoantares@spamgourmet.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |whatwg2k101.d.xenoantares@sp
                   |                            |amgourmet.com
             Status|RESOLVED                    |REOPENED
         Resolution|NEEDSINFO                   |




--- Comment #2 from x.a <whatwg2k101.d.xenoantares@spamgourmet.com>  2010-01-10 15:27:05 ---
Appreciate your comment.

Imagine using an 'input' with the 'type' attribute in 'Number' state in order
to get a user input eg regarding the minutes part of a geographical location.

You may want to allow 10th or even 100th, so you specify attributes 'min="0"',
'max="59.99"' and 'step="0.01"', as the default step (and step scaling) are
standardized to be 1.


So far, so fine. Maybe the issue is digging to deep into spheres of the UA and
their decisions regarding an actual UI implementation. But you surely don't
want to have a user have to click 100 times to adjust the entire value by just
one minute!

It would be reasonable to use a 'granularity' for the UI controls to consider
different from the 'granularity' used in the validation process. (In this
example it might be a 1 minute 'controlstep', so to cover any case the UA/UI
might appreciate a hint or a binding attribute value.) To exhaust the
'granularity' granted in the validation process, the user would have to type a
value in.


As you point out, that only makes sense, if the 'controlstep' was coarser than
the '(validation)step'.


-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Sunday, 10 January 2010 15:27:07 UTC