- From: Phillips, Addison <addison@lab126.com>
- Date: Sat, 16 Jul 2011 11:10:11 -0700
- To: "public-i18n-core@w3.org" <public-i18n-core@w3.org>
More commenting :-) 1. Section 4.10.3. The "accept-charset" field is said to "gives the character encodings that are to be used for the submission". Is this a real limitation on the encodings used? Is there a default value (presumably the page encoding)? 2. Section 4.10.7.1.5. The email address validation scheme quotes ABNF from RFC 5322 and doesn't appear to allow addresses that are IDNA. While EAI is kinda slow moving, shouldn't HTML5 allow for it? 3. Section 4.10.7. Various date/time types. (previous comments apply) 4. Section 4.10.7.1.7. Contains this note: -- The format shown to the user is independent of the format used for form submission. Browsers are encouraged to use user interfaces that present dates and times according to the conventions of the user's preferred locale. -- Should we encourage the use of the *page's* preferred locale? It would be best if we could provide a way for page authors to create a consistent user experience. Work on the ECMAScript I18N extension may eventually help here, but only for formatting displayed values---this section seems to imply that the user agent have a built-in date/time control set that may not be scriptable. Although a given user agent won't necessarily support the requested locale, I would suggest providing a <form> attribute or a field attribute to allow the page itself to request a given locale using a BCP 47 language tag. 5. Section 4.10.7.1.9. The 'month' type doesn't allow for 13 month calendars (undecimber). 6. Section 4.10.7. The type 'datetime-local' is used for floating times. There is no matching 'date' version or 'time' version. The effect of this type is to allow a form to show times such that the user-agent doesn't modify the fields when displaying them. This may not work well with non-Gregorian calendars, please note. 7. Section 4.10.7. It would be useful to be able to set the time zone on a date or time field using an Olson id or the GMT+/- string. 8. Section 4.10.7.1.13. The 'number' type allows only for Western style (ASCII) digits and parsing. There is no note about localized display by the user-agent (as there was with dates, for example). Digit shaping should be allowed as should localized input/display. 9. Section 4.10.7.1.18. The 'file upload' says: Path components should be separated from each other using U+005C REVERSE SOLIDUS character (\). Should the path separator be the forward slash instead? Addison Phillips Globalization Architect (Lab126) Chair (W3C I18N WG) Internationalization is not a feature. It is an architecture.
Received on Saturday, 16 July 2011 18:10:39 UTC