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 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. On Tue, May 13, 2014 at 6:17 PM, Matthew Noorenberghe < mattn+wha...@mozilla.com> 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 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 > >  > http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#attr-fe-autocomplete >