- From: John Tamplin <jat@google.com>
- Date: Thu, 26 Jan 2012 04:48:49 -0500
On Fri, Jan 20, 2012 at 6:28 PM, Ilya Sherman <isherman at chromium.org> wrote: > > Maybe some of the supported keywords could be dropped (e.g. those that > are > > not recommended to use). Since there's no legacy yet, we can reject bad > > keywords completely and only support the best practice keywords. > Similarly, > > there's address-line1, address-line2 and address-line3 -- maybe they > could > > be dropped and encourage authors to use a textarea for address? > > > > Dropping the discouraged keywords (e.g. "phone-local-prefix") certainly > seems reasonable to me, in the interest of keeping the predefined token set > relatively small. On the other hand, these seven discouraged keywords were > added to the initial proposal because a nontrivial number of existing forms > currently structure their fields in this way. I'd love to get more > people's insights into this tradeoff. I'll go ahead and fork off a thread > specifically for discussion of the specific choice of tokens, so that this > thread can remain focused on the more high-level details of the proposal. > > For the address lines, I don't think it's practical to encourage authors to > use a textarea rather than separate fields. To the best of my knowledge, > almost no website currently uses textareas for this purpose, so textareas > are only a theoretical best practice -- users and developers both tend to > expect the address lines to be separate fields. Moreover, transitioning > from separate fields to a single textarea would require backend migrations > (in the parsing code, the database, or both) in order to store the data > entered in this new format. That would negate one of the key advantages of > this proposal, i.e. the lack of need for backend migrations, relative to > ECML. I don't see how requiring forms to lump the address together is going to help -- if the database stores the fields separately, other APIs that the backend needs to give the address to (such as shipping carriers, address cleanup/geocoding, etc) expects separate fields then all you are doing is pushing the parsing of the address off to the backend rather than letting the user see it. Also, I think a properly localized (ie, fields dependent on the country given) address form is much more likely to get the correct data from the user than just asking them to enter a blob of text. One question -- how does this fit with, say, a <select> element for country that shows localized country names? Can it be "autocompleted" as well? If so, does it match on the localized names, the value (which might be an ISO 2 or 3-digit code, or something unique to the app), or what? -- John A. Tamplin Software Engineer (GWT), Google
Received on Thursday, 26 January 2012 01:48:49 UTC