Re: [whatwg] @autocomplete sections

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

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

Received on Thursday, 15 May 2014 01:59:46 UTC