Re: [whatwg] @autocomplete sections

On Tue, 13 May 2014, Matthew Noorenberghe wrote:
> 
> While looking at implementing the new autocomplete attribute syntax, I 
> was wondering about the driver for section-* tokens.  The example in the 
> spec[1] with multiple shipping addresses for one checkout isn't 
> something I've seen done in the wild in one flow. In the example, how 
> did the website know that the two items should be in different sections 
> in the first place?
> [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#attr-fe-autocomplete

Presumably the site asked who the items were for in an earlier flow. For 
example, when purchasing flowers online it's common for sites to let you 
pick the recipient of the flower when you pick the flower, and then later 
they ask for all the addresses at once. If they used autocomplete="", 
they'd want each recipient to have their own section-* marker.


> Also, why is sectioning better than using two forms for the example in 
> the spec?

Well if they're going to be submitted all together, they're one form. I 
don't really understand how it would work to have two forms if you need to 
fill them both in and have one submit button.


> One of the complexities with arbitrary sectioning is how to display the 
> multiple sections in the browser's rAc UI.

If rAc() is faced with something it can't work out how to display, it can 
just return "disabled". That occurs with far more than just "section-*". 
For example, what would you do if the form had just a bday-day, cc-type, 
and a tel-local-suffix field? It's hard to imagine that rAc() could do 
anything useful with that.


> Choosing multiple sets of information for different sections at once can 
> be overwhelming/confusing. How are UAs expected to communicate what 
> section goes with each profile? Surely UAs aren't going to show "red" 
> and "blue" for the example in the spec but it's not so straightforward 
> to find an appropriate label/heading.

The section-* labels certainly shouldn't be used, agreed.

It's a good point that there isn't a good way to label the different 
sections in rAc(). Note that section-* long predates rAc() in the spec. 
It's also useful for non-rAc() autofill. For example, if a browser lets 
you pick an address from an address-line1 field's autofill dropdown, and 
then autofills all the other fields (address-line2, postal-code, etc), the 
section-* keywords lets it know that it should only do so within one 
region of the form, and that the other address-line2 fields are for 
another address. Same with e.g. if the form asks for names and birthdays 
of everyone in one's family: the UA would let you pick a name for the 
"name" field, and could autofill the "bday" field, but without the 
section-* labels it would have no way to know that the second name field 
is related to the second bday field and not the first bday field.


On Wed, 14 May 2014, Ilya Sherman wrote:
>
> 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.

The examples above, as well as the Japanese vs Romanised name example in 
the spec, all seem like pretty strong use cases to me.


> For example, a social network might ask for multiple points of contact 
> info, e.g. a home address and also a work address.  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.
> 
> 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.  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.)
> 
> 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.

Right.


On Wed, 14 May 2014, Matthew Noorenberghe wrote:
> 
> 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-*.

We could do that, but what's the advantage? Does it really simplify 
implementations meaningfully?

One of the two only examples of section-* in the spec uses both section-* 
and shipping at the same time, to indicate to the UA that the addresses it 
should offer for those two addresses are shipping addresses, not billing 
addresses. (For example, when I used a PO Box for my billing address and a 
house address for my shipping address, I could imagine the UA noticing 
these two addresses are always used for shipping vs billing and only 
offering the PO Box address for billing fields.)


> > 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 should definitely not be any heuristics based on the values of the 
section-* keywords. Those are opaque.

It seems likely to me that rAc() just wouldn't work for these fields.

We could consider allowing "home" and "work" in addition to "shipping" and 
"billing", and removing them from the telecom level, replacing them maybe 
with "landline" or some such. But it's not clear to me that this is a 
particularly strong win.


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

Neither.


> Does allowing the home/work tokens before an address address this case? 

Not really.


> If not, could you provide a real-world example of this different class 
> of address? Can we add a new token for it instead?

If we go the route of adding new keywords for each use case that section-* 
could apply to, it's not clear to me where that ends. Consider in 
particular the flower ordering site case and the family information case. 
do we add "recipient-N" keywords where N is a number? Or "family-self",
"family-spouse-N", "family-child-N", "family-parent-N", etc?


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

I agree that for rAc() this isn't really something you can do much with. 
But forms and autofill don't have to be only used with rAc().


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

I'm not sure what you're proposing here. Do you mean we'd have <fieldset> 
elements that are not rendered, with their "contents" being outside the 
element? If the goal is just to provide a caption for a section-* of 
fields for use by rAc(), we can probably find a simpler solution. For 
example, we could pass requestAutocomplete() a dictionary where the keys 
are the section-* labels, and the values are the headings to use. This 
would actually allow us to provide even more information, e.g. help text 
to show for certain fields, etc.

Honestly, though, I would recommend that we wait to see how many forms use 
section-* at all before worrying about how rAc() works with them.


On Wed, 14 May 2014, Ilya Sherman wrote:
> 
> 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.

I agree that they're probably not used much, but I think it makes sense to 
support them because without them a form can basically not use 
autocomplete="" at all for any fields that have duplicates. There's plenty 
of cases where autofill for subsets of a form makes sense and would be 
possible, but where without section-* the autofill would just be confused.

It doesn't seem to me that, outside of rAc(), section-* has much of an 
implementation burden. It's essentially just a way to split the form into 
subforms for the purpose of autofill only.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Thursday, 22 May 2014 18:10:13 UTC