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.

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

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.

On Tue, May 13, 2014 at 6:17 PM, Matthew Noorenberghe <> wrote:

> Hello,
> 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?
> The only idea I'm thinking of is a checkbox to indicate an item was a gift
> when it was added to the cart. If the website already knew about the
> different shipping addresses of the user when the item was added to the
> cart, it wouldn't really need to autocomplete the shipping address again.
> Example:
> * On the page for product A, the user chooses address A from a <select>
> that the page populated from information on past shipping addresses or
> checks a checkbox that the item is a gift.
> * The user clicks "add to cart" for product A
> * On the page for product B, the user chooses address B from a <select>
> that the page populated from information on past shipping addresses.
> * The user clicks "add to cart" for product B
> * The checkout page knows that products A and B are getting shipped to
> different addresses so it can show them in different sections.
> Also, why is sectioning better than using two forms for the example in the
> spec? One of the complexities with arbitrary sectioning is how to display
> the multiple sections in the browser's rAc UI. 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.
> A <fieldset> could have multiple sections so one can't just find the first
> <fieldset> parent and use its <legend>. It's also possible there isn't a
> <fieldset> or <legend> and so UAs may then use the outlining algorithm to
> find headings. I'm not sure if the ability to have arbitrary sections is
> worth the complexity this adds. How are other UAs planning on supporting
> multiple arbitrary sections? I'd like to hear more of an argument
> supporting this feature before implementing it. Is this something that
> others intend to implement?
> Thanks,
> Matthew Noorenberghe
> [1]

Reply via email to