|
|
Index: chrome/browser/resources/options/autofill_edit_address_overlay.html |
diff --git a/chrome/browser/resources/options/autofill_edit_address_overlay.html b/chrome/browser/resources/options/autofill_edit_address_overlay.html |
index a54bc858a49d1336d7a820ecebe4ac8ee5386e59..b33889292567733f62f885d77a72ce12e4ecd280 100644 |
--- a/chrome/browser/resources/options/autofill_edit_address_overlay.html |
+++ b/chrome/browser/resources/options/autofill_edit_address_overlay.html |
@@ -2,70 +2,29 @@ |
<div class="close-button"></div> |
<h1 id="autofill-address-title"></h1> |
<div class="content-area"> |
- <div> |
- <div id="autofill-name-labels"> |
- <span i18n-content="autofillFirstNameLabel"></span> |
- <span i18n-content="autofillMiddleNameLabel"></span> |
- <span i18n-content="autofillLastNameLabel"></span> |
- </div> |
- </div> |
- <div> |
- <list id="full-name-list"></list> |
- </div> |
- |
- <label class="settings-row"> |
- <div i18n-content="autofillCompanyNameLabel"></div> |
- <input id="company-name" type="text"> |
- </label> |
- |
- <label class="settings-row"> |
- <div i18n-content="autofillAddrLine1Label"></div> |
- <input id="addr-line-1" type="text"> |
- </label> |
- |
- <label class="settings-row"> |
- <div i18n-content="autofillAddrLine2Label"></div> |
- <input id="addr-line-2" type="text"> |
- </label> |
- |
- <div class="input-group settings-row"> |
- <label> |
- <div i18n-content="autofillCityLabel"></div> |
- <input id="city" type="text"> |
- </label> |
- |
- <label> |
- <div id="state-label"></div> |
- <input id="state" type="text"> |
- </label> |
- |
- <label> |
- <div id="postal-code-label"></div> |
- <input id="postal-code" type="text"> |
- </label> |
+ <div id="autofill-edit-address-fields"> |
</div> |
<div class="settings-row"> |
<label> |
<div i18n-content="autofillCountryLabel"></div> |
- <select id="country"></select> |
+ <select class="country" field="country"></select> |
</label> |
</div> |
<div class="input-group settings-row"> |
<div> |
<div i18n-content="autofillPhoneLabel"></div> |
- <list id="phone-list" |
- i18n-values="placeholder:autofillAddPhonePlaceholder"></list> |
+ <list class="phone-list" field="phone" |
+ i18n-values="placeholder:autofillAddPhonePlaceholder"></list> |
</div> |
<div> |
<div i18n-content="autofillEmailLabel"></div> |
- <list id="email-list" |
- i18n-values="placeholder:autofillAddEmailPlaceholder"></list> |
+ <list class="email-list" field="email" |
+ i18n-values="placeholder:autofillAddEmailPlaceholder"></list> |
</div> |
</div> |
- |
</div> |
<div class="action-area button-strip"> |
@@ -75,3 +34,32 @@ |
class="default-button" i18n-content="ok" disabled></button> |
</div> |
</div> |
+ |
+<div hidden> |
+ <div id="autofill-address-row-template" class="input-group settings-row"> |
+ </div> |
+ |
+ <div id="autofill-full-name-list-template"> |
+ <div> |
+ <div class="autofill-name-labels"> |
+ <span i18n-content="autofillFirstNameLabel"></span> |
Evan Stade
2014/04/25 20:02:18
I think we should standardize the number of name f
I think we should standardize the number of name fields (i.e. just have one full
name field instead of 3 name pieces here, to match the dialog)
please use gerrit instead
2014/04/28 15:49:44
Done.
On 2014/04/25 20:02:18, Evan Stade wrote:
> I think we should standardize the number of name fields (i.e. just have one
full
> name field instead of 3 name pieces here, to match the dialog)
Done.
Evan Stade
2014/04/28 23:23:16
+isherman, any opinion on this change?
On 2014/04/28 15:49:44, Rouslan Solomakhin wrote:
> On 2014/04/25 20:02:18, Evan Stade wrote:
> > I think we should standardize the number of name fields (i.e. just have one
> full
> > name field instead of 3 name pieces here, to match the dialog)
>
> Done.
+isherman, any opinion on this change?
Ilya Sherman
2014/04/28 23:43:44
Websites will often request first, middle, and las
On 2014/04/28 23:23:16, Evan Stade wrote:
> On 2014/04/28 15:49:44, Rouslan Solomakhin wrote:
> > On 2014/04/25 20:02:18, Evan Stade wrote:
> > > I think we should standardize the number of name fields (i.e. just have
one
> > full
> > > name field instead of 3 name pieces here, to match the dialog)
> >
> > Done.
>
> +isherman, any opinion on this change?
Websites will often request first, middle, and last names separately. At the
same time, Chrome has very basic heuristics in place to parse a full name into
components. If we offer just a single full name field, then users have no
ability to correct Chrome's mistakes if they want to. That's not great -- it
means that Autofill will *never* work correctly for users like "Leonardo da
Vinci", or any other name that our simple heuristics fail on.
For rAc, we have the opportunity to explicitly discourage websites from asking
for tokenized names. For regular Autofill, we have to deal with the common
legacy case. So, I think we need to keep some way for users to correct Chrome's
tokenization of their name. If we want a single field by default, we could do
something complex like what https://contacts.google.com does.
Evan Stade
2014/04/28 23:56:37
Isn't the inverse also true? If we have multiple i
On 2014/04/28 23:43:44, Ilya Sherman wrote:
> On 2014/04/28 23:23:16, Evan Stade wrote:
> > On 2014/04/28 15:49:44, Rouslan Solomakhin wrote:
> > > On 2014/04/25 20:02:18, Evan Stade wrote:
> > > > I think we should standardize the number of name fields (i.e. just have
> one
> > > full
> > > > name field instead of 3 name pieces here, to match the dialog)
> > >
> > > Done.
> >
> > +isherman, any opinion on this change?
>
> Websites will often request first, middle, and last names separately. At the
> same time, Chrome has very basic heuristics in place to parse a full name into
> components. If we offer just a single full name field, then users have no
> ability to correct Chrome's mistakes if they want to. That's not great -- it
> means that Autofill will *never* work correctly for users like "Leonardo da
> Vinci", or any other name that our simple heuristics fail on.
>
Isn't the inverse also true? If we have multiple input fields, then Yao Ming can
add his name in chrome://settings/autofill, which will work for
autocomplete="given-name" and "family-name", but when we try to fill it into a
full name field it will come out as Ming Yao, and he can't fix that.
Also, wouldn't Leonardo da Vinci work with our heuristics? First name is the
first word (Leonardo), last name is everything else (da Vinci). But yea, Billy
Bob Thornton wouldn't work.
Seems like either way, it won't work for someone.
> For rAc, we have the opportunity to explicitly discourage websites from asking
> for tokenized names. For regular Autofill, we have to deal with the common
> legacy case. So, I think we need to keep some way for users to correct
Chrome's
> tokenization of their name. If we want a single field by default, we could do
> something complex like what https://contacts.google.com does.
But data typed into a rAc dialog feeds into the legacy cases as well...
Ilya Sherman
2014/04/29 00:08:29
I'm not following this example. I think you mean
On 2014/04/28 23:56:37, Evan Stade wrote:
> On 2014/04/28 23:43:44, Ilya Sherman wrote:
> > On 2014/04/28 23:23:16, Evan Stade wrote:
> > > On 2014/04/28 15:49:44, Rouslan Solomakhin wrote:
> > > > On 2014/04/25 20:02:18, Evan Stade wrote:
> > > > > I think we should standardize the number of name fields (i.e. just
have
> > one
> > > > full
> > > > > name field instead of 3 name pieces here, to match the dialog)
> > > >
> > > > Done.
> > >
> > > +isherman, any opinion on this change?
> >
> > Websites will often request first, middle, and last names separately. At
the
> > same time, Chrome has very basic heuristics in place to parse a full name
into
> > components. If we offer just a single full name field, then users have no
> > ability to correct Chrome's mistakes if they want to. That's not great --
it
> > means that Autofill will *never* work correctly for users like "Leonardo da
> > Vinci", or any other name that our simple heuristics fail on.
> >
>
> Isn't the inverse also true? If we have multiple input fields, then Yao Ming
can
> add his name in chrome://settings/autofill, which will work for
> autocomplete="given-name" and "family-name", but when we try to fill it into a
> full name field it will come out as Ming Yao, and he can't fix that.
I'm not following this example. I think you mean that the full name field
always fills as "first name + middle name + last name", whereas for some names
the family name should come first? If so, I think that's something that we
should fix as best we can as part of the localization work.
> Also, wouldn't Leonardo da Vinci work with our heuristics? First name is the
> first word (Leonardo), last name is everything else (da Vinci). But yea, Billy
> Bob Thornton wouldn't work.
"da" would be treated as a middle name, rather than as part of the last name.
> Seems like either way, it won't work for someone.
>
> > For rAc, we have the opportunity to explicitly discourage websites from
asking
> > for tokenized names. For regular Autofill, we have to deal with the common
> > legacy case. So, I think we need to keep some way for users to correct
> Chrome's
> > tokenization of their name. If we want a single field by default, we could
do
> > something complex like what https://contacts.google.com does.
>
> But data typed into a rAc dialog feeds into the legacy cases as well...
True, and users can edit data originally entered into an rAc via the
chrome://settings/autofill UI.
Evan Stade
2014/04/29 00:24:41
yes, that is what I mean.
On 2014/04/29 00:08:29, Ilya Sherman wrote:
> On 2014/04/28 23:56:37, Evan Stade wrote:
> > On 2014/04/28 23:43:44, Ilya Sherman wrote:
> > > On 2014/04/28 23:23:16, Evan Stade wrote:
> > > > On 2014/04/28 15:49:44, Rouslan Solomakhin wrote:
> > > > > On 2014/04/25 20:02:18, Evan Stade wrote:
> > > > > > I think we should standardize the number of name fields (i.e. just
> have
> > > one
> > > > > full
> > > > > > name field instead of 3 name pieces here, to match the dialog)
> > > > >
> > > > > Done.
> > > >
> > > > +isherman, any opinion on this change?
> > >
> > > Websites will often request first, middle, and last names separately. At
> the
> > > same time, Chrome has very basic heuristics in place to parse a full name
> into
> > > components. If we offer just a single full name field, then users have no
> > > ability to correct Chrome's mistakes if they want to. That's not great --
> it
> > > means that Autofill will *never* work correctly for users like "Leonardo
da
> > > Vinci", or any other name that our simple heuristics fail on.
> > >
> >
> > Isn't the inverse also true? If we have multiple input fields, then Yao Ming
> can
> > add his name in chrome://settings/autofill, which will work for
> > autocomplete="given-name" and "family-name", but when we try to fill it into
a
> > full name field it will come out as Ming Yao, and he can't fix that.
>
> I'm not following this example. I think you mean that the full name field
> always fills as "first name + middle name + last name", whereas for some names
> the family name should come first? If so, I think that's something that we
> should fix as best we can as part of the localization work.
yes, that is what I mean.
>
> > Also, wouldn't Leonardo da Vinci work with our heuristics? First name is the
> > first word (Leonardo), last name is everything else (da Vinci). But yea,
Billy
> > Bob Thornton wouldn't work.
>
> "da" would be treated as a middle name, rather than as part of the last name.
That seems like a mistake. How often do people actually type middle names?
Probably less often than having 2-word last names at least according to my
totally unfounded guesstimates. If site (a) uses full-name and then site (b)
uses separate names, the default should be to use ALL the name from (a) on (b),
without forcing the user to navigate to chrome://settings/autofill, which
realistically is rarely if ever going to happen.
>
> > Seems like either way, it won't work for someone.
> >
> > > For rAc, we have the opportunity to explicitly discourage websites from
> asking
> > > for tokenized names. For regular Autofill, we have to deal with the
common
> > > legacy case. So, I think we need to keep some way for users to correct
> > Chrome's
> > > tokenization of their name. If we want a single field by default, we
could
> do
> > > something complex like what https://contacts.google.com does.
> >
> > But data typed into a rAc dialog feeds into the legacy cases as well...
>
> True, and users can edit data originally entered into an rAc via the
> chrome://settings/autofill UI.
Ilya Sherman
2014/04/29 00:37:29
Lots of web forms ask for a middle initial, so peo
On 2014/04/29 00:24:41, Evan Stade wrote:
> On 2014/04/29 00:08:29, Ilya Sherman wrote:
> > On 2014/04/28 23:56:37, Evan Stade wrote:
> > > On 2014/04/28 23:43:44, Ilya Sherman wrote:
> > > > On 2014/04/28 23:23:16, Evan Stade wrote:
> > > > > On 2014/04/28 15:49:44, Rouslan Solomakhin wrote:
> > > > > > On 2014/04/25 20:02:18, Evan Stade wrote:
> > > > > > > I think we should standardize the number of name fields (i.e. just
> > have
> > > > one
> > > > > > full
> > > > > > > name field instead of 3 name pieces here, to match the dialog)
> > > > > >
> > > > > > Done.
> > > > >
> > > > > +isherman, any opinion on this change?
> > > >
> > > > Websites will often request first, middle, and last names separately.
At
> > the
> > > > same time, Chrome has very basic heuristics in place to parse a full
name
> > into
> > > > components. If we offer just a single full name field, then users have
no
> > > > ability to correct Chrome's mistakes if they want to. That's not great
--
> > it
> > > > means that Autofill will *never* work correctly for users like "Leonardo
> da
> > > > Vinci", or any other name that our simple heuristics fail on.
> > > >
> > >
> > > Isn't the inverse also true? If we have multiple input fields, then Yao
Ming
> > can
> > > add his name in chrome://settings/autofill, which will work for
> > > autocomplete="given-name" and "family-name", but when we try to fill it
into
> a
> > > full name field it will come out as Ming Yao, and he can't fix that.
> >
> > I'm not following this example. I think you mean that the full name field
> > always fills as "first name + middle name + last name", whereas for some
names
> > the family name should come first? If so, I think that's something that we
> > should fix as best we can as part of the localization work.
>
> yes, that is what I mean.
>
> >
> > > Also, wouldn't Leonardo da Vinci work with our heuristics? First name is
the
> > > first word (Leonardo), last name is everything else (da Vinci). But yea,
> Billy
> > > Bob Thornton wouldn't work.
> >
> > "da" would be treated as a middle name, rather than as part of the last
name.
>
> That seems like a mistake. How often do people actually type middle names?
> Probably less often than having 2-word last names at least according to my
> totally unfounded guesstimates. If site (a) uses full-name and then site (b)
> uses separate names, the default should be to use ALL the name from (a) on
(b),
> without forcing the user to navigate to chrome://settings/autofill, which
> realistically is rarely if ever going to happen.
Lots of web forms ask for a middle initial, so people type middle names
frequently.
If we think that people never go to chrome://settings/autofill, then how about
we just delete all of this code and call it a day? </strawman>
> > > Seems like either way, it won't work for someone.
> > >
> > > > For rAc, we have the opportunity to explicitly discourage websites from
> > asking
> > > > for tokenized names. For regular Autofill, we have to deal with the
> common
> > > > legacy case. So, I think we need to keep some way for users to correct
> > > Chrome's
> > > > tokenization of their name. If we want a single field by default, we
> could
> > do
> > > > something complex like what https://contacts.google.com does.
> > >
> > > But data typed into a rAc dialog feeds into the legacy cases as well...
> >
> > True, and users can edit data originally entered into an rAc via the
> > chrome://settings/autofill UI.
Evan Stade
2014/04/29 18:19:03
Into full name fields? If the site has a middle in
On 2014/04/29 00:37:29, Ilya Sherman wrote:
> On 2014/04/29 00:24:41, Evan Stade wrote:
> > On 2014/04/29 00:08:29, Ilya Sherman wrote:
> > > On 2014/04/28 23:56:37, Evan Stade wrote:
> > > > On 2014/04/28 23:43:44, Ilya Sherman wrote:
> > > > > On 2014/04/28 23:23:16, Evan Stade wrote:
> > > > > > On 2014/04/28 15:49:44, Rouslan Solomakhin wrote:
> > > > > > > On 2014/04/25 20:02:18, Evan Stade wrote:
> > > > > > > > I think we should standardize the number of name fields (i.e.
just
> > > have
> > > > > one
> > > > > > > full
> > > > > > > > name field instead of 3 name pieces here, to match the dialog)
> > > > > > >
> > > > > > > Done.
> > > > > >
> > > > > > +isherman, any opinion on this change?
> > > > >
> > > > > Websites will often request first, middle, and last names separately.
> At
> > > the
> > > > > same time, Chrome has very basic heuristics in place to parse a full
> name
> > > into
> > > > > components. If we offer just a single full name field, then users
have
> no
> > > > > ability to correct Chrome's mistakes if they want to. That's not
great
> --
> > > it
> > > > > means that Autofill will *never* work correctly for users like
"Leonardo
> > da
> > > > > Vinci", or any other name that our simple heuristics fail on.
> > > > >
> > > >
> > > > Isn't the inverse also true? If we have multiple input fields, then Yao
> Ming
> > > can
> > > > add his name in chrome://settings/autofill, which will work for
> > > > autocomplete="given-name" and "family-name", but when we try to fill it
> into
> > a
> > > > full name field it will come out as Ming Yao, and he can't fix that.
> > >
> > > I'm not following this example. I think you mean that the full name field
> > > always fills as "first name + middle name + last name", whereas for some
> names
> > > the family name should come first? If so, I think that's something that
we
> > > should fix as best we can as part of the localization work.
> >
> > yes, that is what I mean.
> >
> > >
> > > > Also, wouldn't Leonardo da Vinci work with our heuristics? First name is
> the
> > > > first word (Leonardo), last name is everything else (da Vinci). But yea,
> > Billy
> > > > Bob Thornton wouldn't work.
> > >
> > > "da" would be treated as a middle name, rather than as part of the last
> name.
> >
> > That seems like a mistake. How often do people actually type middle names?
> > Probably less often than having 2-word last names at least according to my
> > totally unfounded guesstimates. If site (a) uses full-name and then site (b)
> > uses separate names, the default should be to use ALL the name from (a) on
> (b),
> > without forcing the user to navigate to chrome://settings/autofill, which
> > realistically is rarely if ever going to happen.
>
> Lots of web forms ask for a middle initial, so people type middle names
> frequently.
Into full name fields? If the site has a middle initial field, sure, but we're
talking about a single name field.
Since you brought up the contacts.google.com example, yea, that's a pretty fancy
control. But it also has good heuristics. Somehow it gets Alex de la Hidalga
correct (Alex/de la Hidalga) and Billy Bob Thornton does something reasonable as
well (Billy/Bob/Thornton). I think we should make this a full name field, and
improve our heuristics to the contacts.google.com level of smarts.
As a side note, it parses Leonardo da Vinci as Leonardo/da/Vinci, but I can't
say I've ever actually met a da Vinci, so I don't know if this matters.
>
> If we think that people never go to chrome://settings/autofill, then how about
> we just delete all of this code and call it a day? </strawman>
I don't think that, but I do think we should optimize for the common case of
"user never goes to chrome://settings/autofill".
>
> > > > Seems like either way, it won't work for someone.
This is still the bottom line for me.
Specifically, we think that websites /should/ just ask for full name. Thus if we
just ask for full name, autofill works well with good websites and poorly with
the bad sites that ask for tokenized names. On the other hand, we can ask for
tokenized names, and then autofill works well with bad websites, but not as well
with good websites.
> > > >
> > > > > For rAc, we have the opportunity to explicitly discourage websites
from
> > > asking
> > > > > for tokenized names. For regular Autofill, we have to deal with the
> > common
> > > > > legacy case. So, I think we need to keep some way for users to
correct
> > > > Chrome's
> > > > > tokenization of their name. If we want a single field by default, we
> > could
> > > do
> > > > > something complex like what https://contacts.google.com does.
> > > >
> > > > But data typed into a rAc dialog feeds into the legacy cases as well...
> > >
> > > True, and users can edit data originally entered into an rAc via the
> > > chrome://settings/autofill UI.
Ilya Sherman
2014/04/29 18:59:20
I definitely agree that we should improve our heur
On 2014/04/29 18:19:03, Evan Stade wrote:
> On 2014/04/29 00:37:29, Ilya Sherman wrote:
> > On 2014/04/29 00:24:41, Evan Stade wrote:
> > > On 2014/04/29 00:08:29, Ilya Sherman wrote:
> > > > On 2014/04/28 23:56:37, Evan Stade wrote:
> > > > > On 2014/04/28 23:43:44, Ilya Sherman wrote:
> > > > > > On 2014/04/28 23:23:16, Evan Stade wrote:
> > > > > > > On 2014/04/28 15:49:44, Rouslan Solomakhin wrote:
> > > > > > > > On 2014/04/25 20:02:18, Evan Stade wrote:
> > > > > > > > > I think we should standardize the number of name fields (i.e.
> just
> > > > have
> > > > > > one
> > > > > > > > full
> > > > > > > > > name field instead of 3 name pieces here, to match the dialog)
> > > > > > > >
> > > > > > > > Done.
> > > > > > >
> > > > > > > +isherman, any opinion on this change?
> > > > > >
> > > > > > Websites will often request first, middle, and last names
separately.
> > At
> > > > the
> > > > > > same time, Chrome has very basic heuristics in place to parse a full
> > name
> > > > into
> > > > > > components. If we offer just a single full name field, then users
> have
> > no
> > > > > > ability to correct Chrome's mistakes if they want to. That's not
> great
> > --
> > > > it
> > > > > > means that Autofill will *never* work correctly for users like
> "Leonardo
> > > da
> > > > > > Vinci", or any other name that our simple heuristics fail on.
> > > > > >
> > > > >
> > > > > Isn't the inverse also true? If we have multiple input fields, then
Yao
> > Ming
> > > > can
> > > > > add his name in chrome://settings/autofill, which will work for
> > > > > autocomplete="given-name" and "family-name", but when we try to fill
it
> > into
> > > a
> > > > > full name field it will come out as Ming Yao, and he can't fix that.
> > > >
> > > > I'm not following this example. I think you mean that the full name
field
> > > > always fills as "first name + middle name + last name", whereas for some
> > names
> > > > the family name should come first? If so, I think that's something that
> we
> > > > should fix as best we can as part of the localization work.
> > >
> > > yes, that is what I mean.
> > >
> > > >
> > > > > Also, wouldn't Leonardo da Vinci work with our heuristics? First name
is
> > the
> > > > > first word (Leonardo), last name is everything else (da Vinci). But
yea,
> > > Billy
> > > > > Bob Thornton wouldn't work.
> > > >
> > > > "da" would be treated as a middle name, rather than as part of the last
> > name.
> > >
> > > That seems like a mistake. How often do people actually type middle names?
> > > Probably less often than having 2-word last names at least according to my
> > > totally unfounded guesstimates. If site (a) uses full-name and then site
(b)
> > > uses separate names, the default should be to use ALL the name from (a) on
> > (b),
> > > without forcing the user to navigate to chrome://settings/autofill, which
> > > realistically is rarely if ever going to happen.
> >
> > Lots of web forms ask for a middle initial, so people type middle names
> > frequently.
>
> Into full name fields? If the site has a middle initial field, sure, but we're
> talking about a single name field.
>
> Since you brought up the http://contacts.google.com example, yea, that's a
pretty fancy
> control. But it also has good heuristics. Somehow it gets Alex de la Hidalga
> correct (Alex/de la Hidalga) and Billy Bob Thornton does something reasonable
as
> well (Billy/Bob/Thornton). I think we should make this a full name field, and
> improve our heuristics to the http://contacts.google.com level of smarts.
I definitely agree that we should improve our heuristics.
> As a side note, it parses Leonardo da Vinci as Leonardo/da/Vinci, but I can't
> say I've ever actually met a da Vinci, so I don't know if this matters.
>
> >
> > If we think that people never go to chrome://settings/autofill, then how
about
> > we just delete all of this code and call it a day? </strawman>
>
> I don't think that, but I do think we should optimize for the common case of
> "user never goes to chrome://settings/autofill".
I don't understand this comment. This CL is strictly limited to changing the
behavior of chrome://settings/autofill. Optimizing for the common case of users
who never go to chrome://settings/autofill means this code can do literally
anything, because in the common case users won't see it.
I think that for the chrome://settings/autofill code, we should optimize for the
use cases of users who will ever actually look at chrome://settings/autofill.
For those users, I think more control is better.
> > > > > Seems like either way, it won't work for someone.
>
> This is still the bottom line for me.
>
> Specifically, we think that websites /should/ just ask for full name. Thus if
we
> just ask for full name, autofill works well with good websites and poorly with
> the bad sites that ask for tokenized names. On the other hand, we can ask for
> tokenized names, and then autofill works well with bad websites, but not as
well
> with good websites.
It's true that both tokenizing and recombining tokenized names are
heuristic/imperfect operations. However, I think that combining tokens
correctly is an order of magnitude easier than tokenizing correctly. Hence, I
think we should let users correct the case that Chrome is far more likely to get
wrong based on heuristics.
Or, if we want to be fancy, we can do what https://contacts.google.com does, and
allow users to explicitly specify both the tokenized and the non-tokenized
format for their name.
>
> > > > >
> > > > > > For rAc, we have the opportunity to explicitly discourage websites
> from
> > > > asking
> > > > > > for tokenized names. For regular Autofill, we have to deal with the
> > > common
> > > > > > legacy case. So, I think we need to keep some way for users to
> correct
> > > > > Chrome's
> > > > > > tokenization of their name. If we want a single field by default,
we
> > > could
> > > > do
> > > > > > something complex like what https://contacts.google.com does.
> > > > >
> > > > > But data typed into a rAc dialog feeds into the legacy cases as
well...
> > > >
> > > > True, and users can edit data originally entered into an rAc via the
> > > > chrome://settings/autofill UI.
>
Evan Stade
2014/04/29 19:14:31
Yes, this is a tangent. But it also matters to thi
On 2014/04/29 18:59:20, Ilya Sherman wrote:
> On 2014/04/29 18:19:03, Evan Stade wrote:
> > On 2014/04/29 00:37:29, Ilya Sherman wrote:
> > > On 2014/04/29 00:24:41, Evan Stade wrote:
> > > > On 2014/04/29 00:08:29, Ilya Sherman wrote:
> > > > > On 2014/04/28 23:56:37, Evan Stade wrote:
> > > > > > On 2014/04/28 23:43:44, Ilya Sherman wrote:
> > > > > > > On 2014/04/28 23:23:16, Evan Stade wrote:
> > > > > > > > On 2014/04/28 15:49:44, Rouslan Solomakhin wrote:
> > > > > > > > > On 2014/04/25 20:02:18, Evan Stade wrote:
> > > > > > > > > > I think we should standardize the number of name fields
(i.e.
> > just
> > > > > have
> > > > > > > one
> > > > > > > > > full
> > > > > > > > > > name field instead of 3 name pieces here, to match the
dialog)
> > > > > > > > >
> > > > > > > > > Done.
> > > > > > > >
> > > > > > > > +isherman, any opinion on this change?
> > > > > > >
> > > > > > > Websites will often request first, middle, and last names
> separately.
> > > At
> > > > > the
> > > > > > > same time, Chrome has very basic heuristics in place to parse a
full
> > > name
> > > > > into
> > > > > > > components. If we offer just a single full name field, then users
> > have
> > > no
> > > > > > > ability to correct Chrome's mistakes if they want to. That's not
> > great
> > > --
> > > > > it
> > > > > > > means that Autofill will *never* work correctly for users like
> > "Leonardo
> > > > da
> > > > > > > Vinci", or any other name that our simple heuristics fail on.
> > > > > > >
> > > > > >
> > > > > > Isn't the inverse also true? If we have multiple input fields, then
> Yao
> > > Ming
> > > > > can
> > > > > > add his name in chrome://settings/autofill, which will work for
> > > > > > autocomplete="given-name" and "family-name", but when we try to fill
> it
> > > into
> > > > a
> > > > > > full name field it will come out as Ming Yao, and he can't fix that.
> > > > >
> > > > > I'm not following this example. I think you mean that the full name
> field
> > > > > always fills as "first name + middle name + last name", whereas for
some
> > > names
> > > > > the family name should come first? If so, I think that's something
that
> > we
> > > > > should fix as best we can as part of the localization work.
> > > >
> > > > yes, that is what I mean.
> > > >
> > > > >
> > > > > > Also, wouldn't Leonardo da Vinci work with our heuristics? First
name
> is
> > > the
> > > > > > first word (Leonardo), last name is everything else (da Vinci). But
> yea,
> > > > Billy
> > > > > > Bob Thornton wouldn't work.
> > > > >
> > > > > "da" would be treated as a middle name, rather than as part of the
last
> > > name.
> > > >
> > > > That seems like a mistake. How often do people actually type middle
names?
> > > > Probably less often than having 2-word last names at least according to
my
> > > > totally unfounded guesstimates. If site (a) uses full-name and then site
> (b)
> > > > uses separate names, the default should be to use ALL the name from (a)
on
> > > (b),
> > > > without forcing the user to navigate to chrome://settings/autofill,
which
> > > > realistically is rarely if ever going to happen.
> > >
> > > Lots of web forms ask for a middle initial, so people type middle names
> > > frequently.
> >
> > Into full name fields? If the site has a middle initial field, sure, but
we're
> > talking about a single name field.
> >
> > Since you brought up the http://contacts.google.com example, yea, that's a
> pretty fancy
> > control. But it also has good heuristics. Somehow it gets Alex de la Hidalga
> > correct (Alex/de la Hidalga) and Billy Bob Thornton does something
reasonable
> as
> > well (Billy/Bob/Thornton). I think we should make this a full name field,
and
> > improve our heuristics to the http://contacts.google.com level of smarts.
>
> I definitely agree that we should improve our heuristics.
>
> > As a side note, it parses Leonardo da Vinci as Leonardo/da/Vinci, but I
can't
> > say I've ever actually met a da Vinci, so I don't know if this matters.
> >
> > >
> > > If we think that people never go to chrome://settings/autofill, then how
> about
> > > we just delete all of this code and call it a day? </strawman>
> >
> > I don't think that, but I do think we should optimize for the common case of
> > "user never goes to chrome://settings/autofill".
>
> I don't understand this comment. This CL is strictly limited to changing the
> behavior of chrome://settings/autofill. Optimizing for the common case of
users
> who never go to chrome://settings/autofill means this code can do literally
> anything, because in the common case users won't see it.
Yes, this is a tangent. But it also matters to this CL in that if we make this a
full name field, the quality of our heuristics in parsing that input matters.
>
> I think that for the chrome://settings/autofill code, we should optimize for
the
> use cases of users who will ever actually look at chrome://settings/autofill.
> For those users, I think more control is better.
Lots of metrics are better to have more of. Control, consistency, simplicity,
...
>
> > > > > > Seems like either way, it won't work for someone.
> >
> > This is still the bottom line for me.
> >
> > Specifically, we think that websites /should/ just ask for full name. Thus
if
> we
> > just ask for full name, autofill works well with good websites and poorly
with
> > the bad sites that ask for tokenized names. On the other hand, we can ask
for
> > tokenized names, and then autofill works well with bad websites, but not as
> well
> > with good websites.
>
> It's true that both tokenizing and recombining tokenized names are
> heuristic/imperfect operations. However, I think that combining tokens
> correctly is an order of magnitude easier than tokenizing correctly. Hence, I
> think we should let users correct the case that Chrome is far more likely to
get
> wrong based on heuristics.
If it's so much easier, why don't we do either one correctly?
>
> Or, if we want to be fancy, we can do what https://contacts.google.com does,
and
> allow users to explicitly specify both the tokenized and the non-tokenized
> format for their name.
>
> >
> > > > > >
> > > > > > > For rAc, we have the opportunity to explicitly discourage websites
> > from
> > > > > asking
> > > > > > > for tokenized names. For regular Autofill, we have to deal with
the
> > > > common
> > > > > > > legacy case. So, I think we need to keep some way for users to
> > correct
> > > > > > Chrome's
> > > > > > > tokenization of their name. If we want a single field by default,
> we
> > > > could
> > > > > do
> > > > > > > something complex like what https://contacts.google.com does.
> > > > > >
> > > > > > But data typed into a rAc dialog feeds into the legacy cases as
> well...
> > > > >
> > > > > True, and users can edit data originally entered into an rAc via the
> > > > > chrome://settings/autofill UI.
> >
>
Ilya Sherman
2014/04/29 19:25:03
For names in English, we don't tokenize correctly,
On 2014/04/29 19:14:31, Evan Stade wrote:
> On 2014/04/29 18:59:20, Ilya Sherman wrote:
> > On 2014/04/29 18:19:03, Evan Stade wrote:
> > > On 2014/04/29 00:37:29, Ilya Sherman wrote:
> > > > On 2014/04/29 00:24:41, Evan Stade wrote:
> > > > > On 2014/04/29 00:08:29, Ilya Sherman wrote:
> > > > > > On 2014/04/28 23:56:37, Evan Stade wrote:
> > > > > > > On 2014/04/28 23:43:44, Ilya Sherman wrote:
> > > > > > > > On 2014/04/28 23:23:16, Evan Stade wrote:
> > > > > > > > > On 2014/04/28 15:49:44, Rouslan Solomakhin wrote:
> > > > > > > > > > On 2014/04/25 20:02:18, Evan Stade wrote:
> > > > > > > > > > > I think we should standardize the number of name fields
> (i.e.
> > > just
> > > > > > have
> > > > > > > > one
> > > > > > > > > > full
> > > > > > > > > > > name field instead of 3 name pieces here, to match the
> dialog)
> > > > > > > > > >
> > > > > > > > > > Done.
> > > > > > > > >
> > > > > > > > > +isherman, any opinion on this change?
> > > > > > > >
> > > > > > > > Websites will often request first, middle, and last names
> > separately.
> > > > At
> > > > > > the
> > > > > > > > same time, Chrome has very basic heuristics in place to parse a
> full
> > > > name
> > > > > > into
> > > > > > > > components. If we offer just a single full name field, then
users
> > > have
> > > > no
> > > > > > > > ability to correct Chrome's mistakes if they want to. That's
not
> > > great
> > > > --
> > > > > > it
> > > > > > > > means that Autofill will *never* work correctly for users like
> > > "Leonardo
> > > > > da
> > > > > > > > Vinci", or any other name that our simple heuristics fail on.
> > > > > > > >
> > > > > > >
> > > > > > > Isn't the inverse also true? If we have multiple input fields,
then
> > Yao
> > > > Ming
> > > > > > can
> > > > > > > add his name in chrome://settings/autofill, which will work for
> > > > > > > autocomplete="given-name" and "family-name", but when we try to
fill
> > it
> > > > into
> > > > > a
> > > > > > > full name field it will come out as Ming Yao, and he can't fix
that.
> > > > > >
> > > > > > I'm not following this example. I think you mean that the full name
> > field
> > > > > > always fills as "first name + middle name + last name", whereas for
> some
> > > > names
> > > > > > the family name should come first? If so, I think that's something
> that
> > > we
> > > > > > should fix as best we can as part of the localization work.
> > > > >
> > > > > yes, that is what I mean.
> > > > >
> > > > > >
> > > > > > > Also, wouldn't Leonardo da Vinci work with our heuristics? First
> name
> > is
> > > > the
> > > > > > > first word (Leonardo), last name is everything else (da Vinci).
But
> > yea,
> > > > > Billy
> > > > > > > Bob Thornton wouldn't work.
> > > > > >
> > > > > > "da" would be treated as a middle name, rather than as part of the
> last
> > > > name.
> > > > >
> > > > > That seems like a mistake. How often do people actually type middle
> names?
> > > > > Probably less often than having 2-word last names at least according
to
> my
> > > > > totally unfounded guesstimates. If site (a) uses full-name and then
site
> > (b)
> > > > > uses separate names, the default should be to use ALL the name from
(a)
> on
> > > > (b),
> > > > > without forcing the user to navigate to chrome://settings/autofill,
> which
> > > > > realistically is rarely if ever going to happen.
> > > >
> > > > Lots of web forms ask for a middle initial, so people type middle names
> > > > frequently.
> > >
> > > Into full name fields? If the site has a middle initial field, sure, but
> we're
> > > talking about a single name field.
> > >
> > > Since you brought up the http://contacts.google.com example, yea, that's a
> > pretty fancy
> > > control. But it also has good heuristics. Somehow it gets Alex de la
Hidalga
> > > correct (Alex/de la Hidalga) and Billy Bob Thornton does something
> reasonable
> > as
> > > well (Billy/Bob/Thornton). I think we should make this a full name field,
> and
> > > improve our heuristics to the http://contacts.google.com level of smarts.
> >
> > I definitely agree that we should improve our heuristics.
> >
> > > As a side note, it parses Leonardo da Vinci as Leonardo/da/Vinci, but I
> can't
> > > say I've ever actually met a da Vinci, so I don't know if this matters.
> > >
> > > >
> > > > If we think that people never go to chrome://settings/autofill, then how
> > about
> > > > we just delete all of this code and call it a day? </strawman>
> > >
> > > I don't think that, but I do think we should optimize for the common case
of
> > > "user never goes to chrome://settings/autofill".
> >
> > I don't understand this comment. This CL is strictly limited to changing
the
> > behavior of chrome://settings/autofill. Optimizing for the common case of
> users
> > who never go to chrome://settings/autofill means this code can do literally
> > anything, because in the common case users won't see it.
>
> Yes, this is a tangent. But it also matters to this CL in that if we make this
a
> full name field, the quality of our heuristics in parsing that input matters.
>
> >
> > I think that for the chrome://settings/autofill code, we should optimize for
> the
> > use cases of users who will ever actually look at
chrome://settings/autofill.
> > For those users, I think more control is better.
>
> Lots of metrics are better to have more of. Control, consistency, simplicity,
> ...
>
> >
> > > > > > > Seems like either way, it won't work for someone.
> > >
> > > This is still the bottom line for me.
> > >
> > > Specifically, we think that websites /should/ just ask for full name. Thus
> if
> > we
> > > just ask for full name, autofill works well with good websites and poorly
> with
> > > the bad sites that ask for tokenized names. On the other hand, we can ask
> for
> > > tokenized names, and then autofill works well with bad websites, but not
as
> > well
> > > with good websites.
> >
> > It's true that both tokenizing and recombining tokenized names are
> > heuristic/imperfect operations. However, I think that combining tokens
> > correctly is an order of magnitude easier than tokenizing correctly. Hence,
I
> > think we should let users correct the case that Chrome is far more likely to
> get
> > wrong based on heuristics.
>
> If it's so much easier, why don't we do either one correctly?
For names in English, we don't tokenize correctly, but we do recombine names
correctly (at least, AFAIK). We don't support international names as well
because this part of the code was never internationalized.
> > Or, if we want to be fancy, we can do what https://contacts.google.com does,
> and
> > allow users to explicitly specify both the tokenized and the non-tokenized
> > format for their name.
> >
> > >
> > > > > > >
> > > > > > > > For rAc, we have the opportunity to explicitly discourage
websites
> > > from
> > > > > > asking
> > > > > > > > for tokenized names. For regular Autofill, we have to deal with
> the
> > > > > common
> > > > > > > > legacy case. So, I think we need to keep some way for users to
> > > correct
> > > > > > > Chrome's
> > > > > > > > tokenization of their name. If we want a single field by
default,
> > we
> > > > > could
> > > > > > do
> > > > > > > > something complex like what https://contacts.google.com does.
> > > > > > >
> > > > > > > But data typed into a rAc dialog feeds into the legacy cases as
> > well...
> > > > > >
> > > > > > True, and users can edit data originally entered into an rAc via the
> > > > > > chrome://settings/autofill UI.
> > >
> >
>
Evan Stade
2014/04/30 05:25:22
Yao Ming goes by surname-givenname in English. I'm
On 2014/04/29 19:25:03, Ilya Sherman wrote:
> On 2014/04/29 19:14:31, Evan Stade wrote:
> > On 2014/04/29 18:59:20, Ilya Sherman wrote:
> > > On 2014/04/29 18:19:03, Evan Stade wrote:
> > > > On 2014/04/29 00:37:29, Ilya Sherman wrote:
> > > > > On 2014/04/29 00:24:41, Evan Stade wrote:
> > > > > > On 2014/04/29 00:08:29, Ilya Sherman wrote:
> > > > > > > On 2014/04/28 23:56:37, Evan Stade wrote:
> > > > > > > > On 2014/04/28 23:43:44, Ilya Sherman wrote:
> > > > > > > > > On 2014/04/28 23:23:16, Evan Stade wrote:
> > > > > > > > > > On 2014/04/28 15:49:44, Rouslan Solomakhin wrote:
> > > > > > > > > > > On 2014/04/25 20:02:18, Evan Stade wrote:
> > > > > > > > > > > > I think we should standardize the number of name fields
> > (i.e.
> > > > just
> > > > > > > have
> > > > > > > > > one
> > > > > > > > > > > full
> > > > > > > > > > > > name field instead of 3 name pieces here, to match the
> > dialog)
> > > > > > > > > > >
> > > > > > > > > > > Done.
> > > > > > > > > >
> > > > > > > > > > +isherman, any opinion on this change?
> > > > > > > > >
> > > > > > > > > Websites will often request first, middle, and last names
> > > separately.
> > > > > At
> > > > > > > the
> > > > > > > > > same time, Chrome has very basic heuristics in place to parse
a
> > full
> > > > > name
> > > > > > > into
> > > > > > > > > components. If we offer just a single full name field, then
> users
> > > > have
> > > > > no
> > > > > > > > > ability to correct Chrome's mistakes if they want to. That's
> not
> > > > great
> > > > > --
> > > > > > > it
> > > > > > > > > means that Autofill will *never* work correctly for users like
> > > > "Leonardo
> > > > > > da
> > > > > > > > > Vinci", or any other name that our simple heuristics fail on.
> > > > > > > > >
> > > > > > > >
> > > > > > > > Isn't the inverse also true? If we have multiple input fields,
> then
> > > Yao
> > > > > Ming
> > > > > > > can
> > > > > > > > add his name in chrome://settings/autofill, which will work for
> > > > > > > > autocomplete="given-name" and "family-name", but when we try to
> fill
> > > it
> > > > > into
> > > > > > a
> > > > > > > > full name field it will come out as Ming Yao, and he can't fix
> that.
> > > > > > >
> > > > > > > I'm not following this example. I think you mean that the full
name
> > > field
> > > > > > > always fills as "first name + middle name + last name", whereas
for
> > some
> > > > > names
> > > > > > > the family name should come first? If so, I think that's
something
> > that
> > > > we
> > > > > > > should fix as best we can as part of the localization work.
> > > > > >
> > > > > > yes, that is what I mean.
> > > > > >
> > > > > > >
> > > > > > > > Also, wouldn't Leonardo da Vinci work with our heuristics? First
> > name
> > > is
> > > > > the
> > > > > > > > first word (Leonardo), last name is everything else (da Vinci).
> But
> > > yea,
> > > > > > Billy
> > > > > > > > Bob Thornton wouldn't work.
> > > > > > >
> > > > > > > "da" would be treated as a middle name, rather than as part of the
> > last
> > > > > name.
> > > > > >
> > > > > > That seems like a mistake. How often do people actually type middle
> > names?
> > > > > > Probably less often than having 2-word last names at least according
> to
> > my
> > > > > > totally unfounded guesstimates. If site (a) uses full-name and then
> site
> > > (b)
> > > > > > uses separate names, the default should be to use ALL the name from
> (a)
> > on
> > > > > (b),
> > > > > > without forcing the user to navigate to chrome://settings/autofill,
> > which
> > > > > > realistically is rarely if ever going to happen.
> > > > >
> > > > > Lots of web forms ask for a middle initial, so people type middle
names
> > > > > frequently.
> > > >
> > > > Into full name fields? If the site has a middle initial field, sure, but
> > we're
> > > > talking about a single name field.
> > > >
> > > > Since you brought up the http://contacts.google.com example, yea, that's
a
> > > pretty fancy
> > > > control. But it also has good heuristics. Somehow it gets Alex de la
> Hidalga
> > > > correct (Alex/de la Hidalga) and Billy Bob Thornton does something
> > reasonable
> > > as
> > > > well (Billy/Bob/Thornton). I think we should make this a full name
field,
> > and
> > > > improve our heuristics to the http://contacts.google.com level of
smarts.
> > >
> > > I definitely agree that we should improve our heuristics.
> > >
> > > > As a side note, it parses Leonardo da Vinci as Leonardo/da/Vinci, but I
> > can't
> > > > say I've ever actually met a da Vinci, so I don't know if this matters.
> > > >
> > > > >
> > > > > If we think that people never go to chrome://settings/autofill, then
how
> > > about
> > > > > we just delete all of this code and call it a day? </strawman>
> > > >
> > > > I don't think that, but I do think we should optimize for the common
case
> of
> > > > "user never goes to chrome://settings/autofill".
> > >
> > > I don't understand this comment. This CL is strictly limited to changing
> the
> > > behavior of chrome://settings/autofill. Optimizing for the common case of
> > users
> > > who never go to chrome://settings/autofill means this code can do
literally
> > > anything, because in the common case users won't see it.
> >
> > Yes, this is a tangent. But it also matters to this CL in that if we make
this
> a
> > full name field, the quality of our heuristics in parsing that input
matters.
> >
> > >
> > > I think that for the chrome://settings/autofill code, we should optimize
for
> > the
> > > use cases of users who will ever actually look at
> chrome://settings/autofill.
> > > For those users, I think more control is better.
> >
> > Lots of metrics are better to have more of. Control, consistency,
simplicity,
> > ...
> >
> > >
> > > > > > > > Seems like either way, it won't work for someone.
> > > >
> > > > This is still the bottom line for me.
> > > >
> > > > Specifically, we think that websites /should/ just ask for full name.
Thus
> > if
> > > we
> > > > just ask for full name, autofill works well with good websites and
poorly
> > with
> > > > the bad sites that ask for tokenized names. On the other hand, we can
ask
> > for
> > > > tokenized names, and then autofill works well with bad websites, but not
> as
> > > well
> > > > with good websites.
> > >
> > > It's true that both tokenizing and recombining tokenized names are
> > > heuristic/imperfect operations. However, I think that combining tokens
> > > correctly is an order of magnitude easier than tokenizing correctly.
Hence,
> I
> > > think we should let users correct the case that Chrome is far more likely
to
> > get
> > > wrong based on heuristics.
> >
> > If it's so much easier, why don't we do either one correctly?
>
> For names in English, we don't tokenize correctly, but we do recombine names
> correctly (at least, AFAIK). We don't support international names as well
> because this part of the code was never internationalized.
Yao Ming goes by surname-givenname in English. I'm not sure how prevalent this
is.
>
> > > Or, if we want to be fancy, we can do what https://contacts.google.com
does,
> > and
> > > allow users to explicitly specify both the tokenized and the non-tokenized
> > > format for their name.
> > >
> > > >
> > > > > > > >
> > > > > > > > > For rAc, we have the opportunity to explicitly discourage
> websites
> > > > from
> > > > > > > asking
> > > > > > > > > for tokenized names. For regular Autofill, we have to deal
with
> > the
> > > > > > common
> > > > > > > > > legacy case. So, I think we need to keep some way for users
to
> > > > correct
> > > > > > > > Chrome's
> > > > > > > > > tokenization of their name. If we want a single field by
> default,
> > > we
> > > > > > could
> > > > > > > do
> > > > > > > > > something complex like what https://contacts.google.com does.
> > > > > > > >
> > > > > > > > But data typed into a rAc dialog feeds into the legacy cases as
> > > well...
> > > > > > >
> > > > > > > True, and users can edit data originally entered into an rAc via
the
> > > > > > > chrome://settings/autofill UI.
> > > >
> > >
> >
>
|
+ <span i18n-content="autofillMiddleNameLabel"></span> |
+ <span i18n-content="autofillLastNameLabel"></span> |
+ </div> |
+ </div> |
+ <div> |
+ <list class="full-name-list" field="fullName"></list> |
Evan Stade
2014/04/25 20:02:18
why is this a list inside a div, whereas below you
why is this a list inside a div, whereas below you just have a list?
please use gerrit instead
2014/04/28 15:49:44
No longer relevant, as we're no longer using first
On 2014/04/25 20:02:18, Evan Stade wrote:
> why is this a list inside a div, whereas below you just have a list?
No longer relevant, as we're no longer using first, middle, last template for
names.
|
+ </div> |
+ </div> |
+ |
+ <div id="autofill-addr-lines-template"> |
Evan Stade
2014/04/25 20:02:18
hmm, this should be a textarea, if we are going to
hmm, this should be a textarea, if we are going to follow our own recommendation
to web devs.
please use gerrit instead
2014/04/28 15:49:44
Done.
On 2014/04/25 20:02:18, Evan Stade wrote:
> hmm, this should be a textarea, if we are going to follow our own
recommendation
> to web devs.
Done.
|
+ <div i18n-content="autofillAddrLinesLabel"></div> |
+ <list class="addr-lines" field="addrLines" |
+ i18n-values="placeholder:autofillAddAddrLinePlaceholder"></list> |
+ </div> |
+ |
+ <label id="autofill-field-template"> |
+ <div></div> |
+ <input type="text"> |
+ </label> |
+</div> |