– DRAFT –
Internationalization Working Group Teleconference

<gb> Issue 2011 Define optional normalization of full-width characters in <input type="number"> (by w3cbot) [pending] [tracker] [s:html] [spec-type-issue] [jlreq]

Agenda Review

<gb> Issue 2011 Define optional normalization of full-width characters in <input type="number"> (by w3cbot) [pending] [tracker] [s:html] [spec-type-issue] [jlreq]

addison: added some from me, anything else from wind?

Action Items

<addison> https://github.com/w3c/i18n-actions/issues

<addison> #175

<gb> Action 175 respond to our #2005 (on xfq) due 2025-06-26

<addison> #174

<gb> Action 174 add 'typeface style` to the glossary (on r12a) due 2025-06-19

r12a: created PR, and saw reply

<addison> w3c/i18n-glossary#80

<gb> Pull Request 80 Update 'glyph' definition (by aphillips)

addison: PR above

r12a: could add for today if want?

[seeking for right PR link]

<addison> #173

<gb> Action 173 ping zainab (on aphillips) due 2025-06-19

<addison> #171

<gb> Action 171 revise local-font-access to exclude localhost and talk more about opt-in model (on ZainabAq) due 2025-05-22

addison: copy list and reply some next week

<addison> #169

<gb> Action 169 reply to html 10843 and css 9832 (on aphillips) due 2025-05-08

<r12a> w3c/i18n-actions#174 (comment)

<gb> Action 174 add 'typeface style` to the glossary (on r12a) due 2025-06-19

<addison> #162

<gb> Action 162 poll I18N/CSS for new day/time (on aphillips) due 2025-03-25

<addison> #157

<gb> Action 157 write glossary proposal identifying options and next steps for those options (on aphillips) due 2025-02-20

addison: will tuckle to #162 after this

<addison> #135

addison: #157, discussed last week, and continue this

<gb> Action 135 follow up on XR issue 1393 about locale in session (on aphillips) due 2024-10-17

<addison> #127

<gb> Action 127 make a list of shared topics of interest between TG2 and W3C-I18N (on aphillips) due 2024-09-30

<addison> #33

<gb> Action 33 Close issues marked `close?` or bring to WG for further review (on aphillips)

<addison> #7

<gb> Action 7 Remind shepherds to tend to their awaiting comment resolutions (Evergreen) (on aphillips, xfq, himorin, r12a, bert-github) due 18 Jul 2023

<addison> #4

<gb> Action 4 Work with respec and bikeshed to provide the character markup template as easy-to-use markup (on aphillips) due 27 Jul 2023

Info Share

[none]

Review RADAR

<addison> https://github.com/orgs/w3c/projects/91/views/1

addison: no new request, nothing for review

Pending Issue Review

<addison> https://github.com/w3c/i18n-activity/issues?q=is%3Aissue+is%3Aopen+label%3Apending

addison: #2011, added as agenda, quite interesting one

<gb> Issue 2011 not found

<gb> Issue 2011 Define optional normalization of full-width characters in <input type="number"> (by w3cbot) [pending] [tracker] [s:html] [spec-type-issue] [jlreq]

i18n-activity#2011: full-width characters in `input type=number`

<addison> whatwg/html#11395

<gb> Issue 11395 Define optional normalization of full-width characters in <input type="number"> (by kyouhei-horizumi) [topic: forms] [i18n-tracker] [needs tests] [i18n-jlreq] [i18n-clreq]

addison: in HTML, write specificlly about wide char input into type=number
… issue discussed before around IME on/off etc. and for combinience

<addison> Richard's codepen: https://codepen.io/r12a/pen/PwqVJym

r12a: look at codepen
… type wide full width characters there, you see text grabbled by browser and converted into ascii digits
… my initial question was in Firefox you type wide character see ascii digit
… might not be an issue or not, not sure

<addison> ｑ＋

r12a: this is a situation full width character is handled
… for other scripts, you type numeric in arabic, and see how they are displaied
… if you increment it, for Japanese it's converted into ascii and work, but not for others
… not sure, that is good or not
… problem here, how it works with incrementation or etc.

r12a: don't know what is an answer on this front, but there is some issue/discussion

addison: when you have number input, and you type some, whenyou want to send to the Internet what should happen
… number format is for display, or internal seriarization
… there are many local presentation of number
… immediate problem, I forgot to switch my keyboard, typed fullwidth q+
… it's nice that browser could tell input status
… also it's good if browser handles numeric in format other than ascii, like arabic

addison: it should be good to behave by locale, when you type number

<addison> atsushi: in japan a lot of forms require full-width input

<addison> ... so many people have requirement for how we should type numeric values into the form

<addison> ... such a change is probably the background of this request

<addison> ... physical address, must type numerical values including as character, not as ASCII

addison: weird situation

atsushi: per these messy sitaution, I cannot say neither yes or no if this issue is for Japanese

David: if depends on locale for display, for arabic situation, Japanese numeric to be shown depends on locale
… if I use display locale with Japanese, but site uses locale as arabic, will be shown as arabic?

r12a: if you display in different place, you can use formatting condition for display
… most discussion here, is how input will be handled
… after captured by browser, and some operation made like incrementation, what should be happen

<addison> function showNumber (num) {

<addison> document.getElementById('number').textContent = new Intl.NumberFormat("ja-JP", { style: "currency", currency: "JPY" }).format(

<addison> num);

<addison> }

addison: how should we do for the issue?

xfq: At least the browsers should be able to display and handle native digits, but Chrome currently cannot.

addison: this issue is if we type number with full width digits, input to be handled

xfq: not sure which level is good for users.

addison: if you type wide digit, and used spinner, you would want to get result with spinned?

<addison> new Intl.NumberFormat(locale).format(num)

<addison> new Intl.NumberFormat(locale, { numberingSystem: 'deva'}).format(num);

addison: will you reply to the issue, or I as char hat on?

r12a: not mind

ACTION: addison: add WG comment to html 11395

<gb> Created action #176

<gb> Issue 2011 Define optional normalization of full-width characters in <input type="number"> (by w3cbot) [pending] [tracker] [s:html] [spec-type-issue] [jlreq] [clreq] [i:interaction]

Specdev PR 162: Modernize 'choosing character encodings'

<addison> https://deploy-preview-162--bp-i18n-specdev.netlify.app/#char_choosing

addison: started working on rewritting section of specdev
… early draft above
… as initial set of mustard for encoding

[discussion around mustard text]

addison: third mustard is mostly from charmod-norm

addison: is it better to remove these mustards, most of which says similar thing?

JcK: pieces of mustards, probably says use Unicode, or otherwise useless

addison: make first mustard stronger?

r12a: really rare situation someone might use non-UTF-8 encodings

addison: fourth piece of mustard could be issue
… guidance elsewhere is you should restrict to UTF-8, but this relax it
… could rewrote this as specific case

xfq: existing encoding mappings can be changed/updated

addison: saying not use new field named as encoding, but some header specifies
… could join two items into one

AOB?