W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > April 2009

[Bug 6834] add more number bases to form inputs?

From: <bugzilla@wiggum.w3.org>
Date: Fri, 24 Apr 2009 08:24:34 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1LxGi2-00053E-V7@wiggum.w3.org>

--- Comment #2 from Nick Levinson <Nick_Levinson@yahoo.com>  2009-04-24 08:24:34 ---
As I more or less noted (and why I set priority to P4), the need is infrequent
and specialized, largely to computer scientists, of whom many from time to time
deal in hexadecimal and by extension binary, although octal is much less
common. Base 85 is established for compact expression of IPv6 IP addresses,
which are not yet in use anywhere to my knowledge, but they're not in use
because of difficulties in transitioning from IPv4, and I understand (if I'm
right) that part of the delay is that Internet backbone computers may not be
implementing IPv6 yet and won't until firmware is replaced as they age out. But
it's fair to expect IPv6 to come into implementation during the lifespan of

Mathematicians might justify a wider range of bases, thus extensibility for
which others can write extensions on a base-by-base basis.

For programmers, the most interesting base is 16. Bases 2 and 8 can be handled
with a base-10 field with the caveat of lacking entry validation against
ineligible digits, a solution for which might require a non-HTML facility, such
as a CGI script. And base 85 requires dangerous characters, albeit perhaps

But probably the most important reason for a database management system to have
multiple data types is that sorting methods differ. E.g., by text-sorting rules
"200" comes before "30" because of left-to-right evaluation while by
number-sorting rules "Z" comes before "a" because of the codepoint sequence for
a single-character comparison. In base 16, this is not a problem until users
type in different cases, which in hexadecimal is a meaningless difference, so,
to meet users' expectations and thus a usability standard, case has to be made
sortationally irrelevant to hex entries, even if for style consistency a user
wants case-checking.

Add to that common practices in identifying the base of a number as part of a
spaceless string and usability in meeting users' expectations suggests a need
to accept a wider range of characters during entry, to allow
single-zero-padding, to perform more flexible entry validation, and to ignore
substrings for sortation. In that case, bases 2 and 8 need their own fields or
field extensibility and even decimal needs modification to accept the sometime
practice of suffixing "d" when other numbers are comparably base-labeled.

Bases 2 and 8, if they don't provide entry validation against oversized digits
such as "9" will fail  to meet the usability expectation that when "Q" is
rejected in a number field and when "f" is rejected in a present-day (decimal)
number field then "9" should be rejected in an octal field and "3" in a binary
field. (The "8" and the "2", respectively, also should be rejected unless used
in base identifier strings.)

Falling short in usability is not a technical failure, but if it results in
people not noticing their own errors they'll blame software for technical
errors such as bad sorting or inconsistent behavior. The software may as well
be designed to accommodate these expectations before finalization than await
the virtually inevitable "why doesn't this work" afterwards. Not offering
multiple bases won't be criticized on that ground but not validating or sorting
as expected will be.

Perhaps multiple-base capability is too specialized a demand, although computer
scientists tend to be early adopters of computer technology, so I think it'll
be used, for example, to allow one person to receive and diagnose another
user's issue.

Thank you.


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 Friday, 24 April 2009 08:24:44 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:00:53 UTC