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
Re: [whatwg] @autocomplete sections
- Original Message - On Wed, May 14, 2014 at 6:59 PM, Matthew Noorenberghe mattn+wha...@mozilla.com wrote: IMO it makes sense to ignore section-* tokens for rAc for now. I don't think we need to add home, work, and other such tokens at this time. At least, I haven't heard any concrete demand for them. 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. OK, I filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=25735 to remove it. If others disagree, please comment.
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. 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[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] http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#attr-fe-autocomplete
Re: [whatwg] @autocomplete sections
- 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 fieldsets work like forms 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.
Re: [whatwg] @autocomplete sections
On Wed, May 14, 2014 at 6:59 PM, Matthew Noorenberghe mattn+wha...@mozilla.com wrote: - 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? IMO it makes sense to ignore section-* tokens for rAc for now. I don't think we need to add home, work, and other such tokens at this time. At least, I haven't heard any concrete demand for them. 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. 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). In terms of rAc, I agree that it's hard to present sections delineated by section-* with a meaningful UI. In terms of Chrome's Autofill feature, which originally motivated these tokens, the webpage provides its own UI; Autofill simply draws a small popup menu on top of the page. Hence, the page is able to provide its own context. 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 fieldsets work like forms 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.
[whatwg] @autocomplete sections
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] http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#attr-fe-autocomplete
