----- Original Message -----
> From: "Ilya Sherman" <isher...@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?

> 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).

> 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.

Reply via email to