W3C home > Mailing lists > Public > whatwg@whatwg.org > May 2014

Re: [whatwg] @autocomplete sections

From: Ilya Sherman <isherman@google.com>
Date: Wed, 14 May 2014 20:11:32 -0700
Message-ID: <CAA3nRaiKeQWE=zFM22v0GUJea5+f8BPzp2mri+7WVMj=Za4kEg@mail.gmail.com>
To: whatwg@lists.whatwg.org
On Wed, May 14, 2014 at 6:59 PM, Matthew Noorenberghe <
MattN+whatwg@mozilla.com> wrote:

> ----- Original Message -----
> > From: "Ilya Sherman" <isherman@google.com>
> > To: whatwg@lists.whatwg.org
> > Sent: Wednesday, May 14, 2014 2:33:58 PM
> > Subject: Re: [whatwg] @autocomplete sections
> >
> > That's a good question.  Initially, sections were motivated by the desire
> > to distinguish between "shipping" and "billing", i.e. the recommendation
> > was to use "section-shipping" and "section-billing".  We eventually
> > realized that "shipping" and "billing" are so commonly used that they
> > merited having their own unique tokens.  Now that those are separately
> > canonicalized, the motivation for section-* tokens is much less clear.
>
> OK, that makes sense. If that's the case, could we at least not allow both
> section-* and billing/shipping? i.e. use one token for either "billing",
> "shipping", or section-*.
>
> > However, there are still plenty of cases where sections *could* be
> useful.
> >  For example, a social network might ask for multiple points of contact
> > info, e.g. a home address and also a work address.
>
> I think that would be better addressed by allowing the home/work token
> before addresses so the UA can make a more informed decision about which
> addresses to suggest instead of using heuristics to figure out what the
> arbitrary section suffixes mean and trying to figure out a way to convey
> the distinction to the user in their own language. Simply asking the user
> to choose two addresses in the rAc UI without distinguishing them would be
> the trivial behaviour that would provide a poor UX.
>
> > There are other types
> > of addresses as well: For example, not all mailing addresses, such as
> P.O.
> > boxes, are shipping addresses to which packages can be delivered.  The
> idea
> > is that section-* tokens allow a website to ask for multiple addresses of
> > types that are not necessarily billing or shipping.
>
> Like above, is the UA supposed to figure out what the section suffix
> means? Or shall it simply remember the fact that a given address was used
> with that suffix and prefer the chosen address on another site which
> happens to use the same section name? Does allowing the home/work tokens
> before an address address this case? If not, could you provide a real-world
> example of this different class of address? Can we add a new token for it
> instead?
>

IMO it makes sense to ignore section-* tokens for rAc for now.  I don't
think we need to add "home", "work", and other such tokens at this time.
 At least, I haven't heard any concrete demand for them.

It likely makes sense to remove section-* tokens from the spec entirely.
I'm not sure how much they're used, but I would guess "almost not at all".
 It would be nice to have some concrete numbers; but unfortunately, I'm not
aware of any metrics tracking the usage of section-* tokens.


> > It's certainly possible to use multiple forms, or to use a <fieldset>, to
> > describe such a form.  Using a single form can be more convenient for the
> > user, as there's just a single submit button.
>
> It may be more convenient in terms of the number of clicks but it can be
> more confusing if the user is confronted with UI to choose profiles for
> multiple sections that they can't meaningfully distinguish due to the lack
> of context (partly from the complexity for UAs to use heuristics to make
> guesses).
>

In terms of rAc, I agree that it's hard to present sections delineated by
section-* with a meaningful UI.  In terms of Chrome's Autofill feature,
which originally motivated these tokens, the webpage provides its own UI;
Autofill simply draws a small popup menu on top of the page.  Hence, the
page is able to provide its own context.


> > Using a <fieldset> can be
> > inconvenient for the developer, as fields belonging to the same section
> > might not be listed adjacent to one another in an HTML file.  (Most
> > commonly, this occurs when a developer is allowing presentation to guide
> > their HTML structure, so perhaps we should actively discourage this as an
> > anti-pattern.)
>
> I had thought about proposing that <fieldset>s work like <form>s in that
> fields can be part of a form without being a child (using @form="myForm")
> and have <fieldset> have an "elements" attribute to get a list of all field
> belonging to a fieldset. With that, we could require the section/hint
> tokens to be in @autocomplete on <fieldset> instead of duplicating them in
> every @autocomplete attribute of fields in the section.
>
> > Section tokens were designed before rAc was a consideration.  In Chrome,
> we
> > use them for the "Autofill" feature (which presents a helpful popup as
> the
> > user interacts with a regular ol' visible form), but not for rAc.  It's
> > possible that the use case for section-* tokens is so marginal that it
> > would be better to simply remove them, since "billing" and "shipping"
> cover
> > the common case.
>
> OK, it's useful to know they're not used for rAc in Chrome at this time. I
> feel inclined to have it removed so far.
>
Received on Thursday, 15 May 2014 03:12:37 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:28 UTC