- From: Phillips, Addison <addison@lab126.com>
- Date: Fri, 21 May 2010 11:04:26 -0400
- To: David Clarke <w3@dragonthoughts.co.uk>
- CC: "public-i18n-core@w3.org" <public-i18n-core@w3.org>
Please use the public list to discuss HTML5. Addison Phillips Globalization Architect (Lab126) Chair (W3C I18N, IETF IRI WGs) Internationalization is not a feature. It is an architecture. > -----Original Message----- > From: member-i18n-core-request@w3.org [mailto:member-i18n-core- > request@w3.org] On Behalf Of David Clarke > Sent: Friday, May 21, 2010 5:02 AM > To: member-i18n-core@w3.org > Subject: HTML5 number > > Hello I18n core, > > At the moment, the HTML5 spec defines digits for numbers as U+0030 > DIGIT > ZERO (0) to U+0039 DIGIT NINE (9) in i.e in > http://www.w3.org/TR/html5/infrastructure.html#rules-for-parsing- > non-negative-integers > and > http://www.w3.org/TR/html5/infrastructure.html#valid-floating- > point-number > > Many countries use other digits naturally to express numbers - e.g. > U+06F0 Extended Indic-Arabic Digit Zero (0) to U+06F9 Extended > Indic-Arabic Digit (9) as well as other ranges for Tamil, Gujarati, > Kannada, Thai, Tibetan, Kanji digits. > > Fullwidth digits U+FF10 Fullwidth Digit Zero (0) to U+FF19 > Fullwidth > Digit (9) may also be a problem, as they appear visually similar to > the > U+003x range, but are generated by the same keys under some IMEs. > > Is the current HTML5 specification a reasonable restriction, or > should > we request that extra digit ranges be treated as equivalent? > > Obviously, this will add some processing overhead, but should be > backwards compatible with HTML 4. > > The main problem area I foresee for these is probably in parsing > user > generated data, such as may occur in <input type="number"> fields. > > --- > David Clarke
Received on Friday, 21 May 2010 15:04:59 UTC