search

whatwg / html

HTML Standard
https://html.spec.whatwg.org/multipage/
Other
8.12k stars 2.67k forks source link

autocomplete attribute for street-address details #4986

Open battre opened 5 years ago

battre commented 5 years ago

Currently the HTML Standard seems a bit US centric:

The autocomplete attribute supports the street-address type for an unstructured street address or address-line1, address-line2 and address-line3 for the respective lines.

In Germany and several other countries, websites typically ask for the street name and a house number. In Spain, websites ask for the floor number and door number (I am not a Spanish speaker, I have seen "Num.", "Piso", "Letra", "Esc." on simyo.es for example). Some Brazilian sites ask for a neighborhood (which we might express with an address-levelX but that might be a bit underspecified because I am not aware of a canonical mapping of entities in specific countries).

Should we start a discussion on defining more entities around addresses? I think that just by supporting a street-name, house-number and apartment-number, we could cover a lot of ground.

annevk commented 5 years ago

cc @mnoorenberghe

carstenhag commented 5 years ago

Chrome seems to somehow fill it correctly sometimes, see https://i.imgur.com/QRNxfXL.png (segmueller.de).

This is very rare though and probably depends on the ID's given. Usually, I'd say with a 90% probability, the "street" field from forms gets filled with the street name and the house number. The house number field is then empty and I have to manually edit it, which is unfortunate and could be fixed via the spec.

@annevk / maintainers: Do you need any example websites to show/clarify the issue?

sideshowbarker commented 5 years ago

In Japan, we don’t even have street addresses. Instead, the equivalent is a series of numbers that starts with a district number, and then a block number, and then what’s nominally a specific building number.

I say “nominally” because it’s common for several buildings to actually have the same “building number” (due, e.g., to cases where an older, larger building on a piece of land gets demolished and replaced with two or more smaller buildings on the same land).

So in Japan, in addition to a “building number”, it’s often also necessary to also specify a building name.

When the autocomplete attribute was being defined, I remember we specifically discussed the Japanese-addressing case — as well as other locales/cases with addressing schemes that don’t use street names or that need something more specific than a street address — and (as far as I recall), the relevant set of tokens now in the spec were decided on because trying to define a richer set of tokens to reflect all the possible cases/locales would have ended up with a set that was just too unwieldy in practice.

annevk commented 5 years ago

@carstenhag I think we mainly need to hear from implementers to what extent they are interested in putting work into this as this would also require UI that's aware that if you change the country the address format changes. (E.g., Firefox only supports a single address field at the moment as far as I can tell.)

battre commented 5 years ago

Thank you for sharing the historic context. I appreciate that there is a lot of complexity in international addresses that I am not aware of.

I wonder whether we can still come up with a practical solution that addresses the problem that websites put street and house number into separate fields. We have looked at a few hundred websites in Brazil, Spain, France, Germany and India (focused on non-US websites; acknowledging that this is by no means a representative sample) and noticed this challenge quite frequently in all of these countries but India.

Assuming that websites do not change their UI to support the autocomplete attribute, I wonder how we feel about adding special cases for "a lot but not all countries". I would propose that addresses are too complex to cover all countries with all nuances so we can only get closer to "correct" but never reach it 100%.

Another syntactic idea I had was to go with sub-attributes. Something like address-line1[street-name] and address-line1[house-number]. Would you feel different about this? This could also be used for https://github.com/whatwg/html/issues/4987 as a format specifier cc-exp[mm/yy] to express an expiration in format "MM/YY".

@annevk Regarding implementer interest: I am working for Google on Chrome.

battre commented 5 years ago

@rmondello Do you know anybody who works in this space on WebKit?

annevk commented 5 years ago

cc @whatwg/i18n

xfq commented 5 years ago

FWIW, this may also affect the purpose attribute in APA's Personalization work.

annevk commented 5 years ago

cc @whatwg/a11y per above comment. Does make me wonder how many attributes we need to state the same thing.

littledan commented 5 years ago

@rxaviers and I were chatting about internationalized address formatting. I wonder if the JavaScript Intl API could help by giving data about the required fields for a locale. @sffc

aardrian commented 5 years ago

Given the role autocomplete has in WCAG SC 1.3.5: Identify Input Purpose, I am a fan of any new values that are more internationalized and can benefit more users.

From the user perspective, as long as browsers support it with auto-fill values, then all good.

From the dev perspective, to @sideshowbarker's comment above, too many options and we can expect many devs to use the wrong ones, blunting the accessibility benefit.

aphillips commented 5 years ago

Postal addresses are famously complicated to internationalize, due to the wide variation in formats between (and sometimes within) countries. In addition, there can be differences in what application authors prefer (in terms of the level of granularity they wish to store/process/validate).

There are several ways this might be addressed. On the one hand, we could try to enumerate all postal address components globally such that page authors can always specify the component they mean--door number, prefecture, administrative unit, floor number, etc. As noted by @xfq and @aardrian this could be of use to assistive technologies. On the other hand, we might try to address only specific problems with additions (at a disadvantage to users in countries that need something different).

A key thing to notice is that the language/locale of the page is not the same thing as the country of an address and the form used to collect a specific address needs to be tied to the country it ships to.

@littledan This has less to do with locale than it does with country/region (although there is some locale influence). I would suggest that postal address parts and their regional association be suggested to CLDR as an addition. Intl could then leverage this.

I'll bring this up at W3C I18N WG's next telecon, but we're off this week due to IUC43.

patrickhlauke commented 5 years ago

speaking of WCAG's repurposing (perversion) of the attribute...there are certain situations where an input accepts two different types of information (such as "Username or email address") that currently can't be expressed I think? would it be a massive complication allowing these sorts of multiple values to be used (in order of preference, perhaps)?

annevk commented 5 years ago

@patrickhlauke see #4445.

domenic commented 5 years ago

Some quick comments here, although it looks like there's a lot of good discussion on the key points already...

Another syntactic idea I had was to go with sub-attributes. Something like address-line1[street-name] and address-line1[house-number]. Would you feel different about this?

FWIW I would prefer address-line1-street-name and address-line1-house-number.

From the user perspective, as long as browsers support it with auto-fill values, then all good.

Indeed. I think that's the key point, is whether there are actors in the ecosystem who would actually leverage this. It sounds like Chrome might take the steps @annevk describes (i.e., change their "user information" UI to have separate stree-name/house-number fields when you're in the given country, so that it can successfully autofill later).

Given the precedent in https://github.com/whatwg/html/issues/3745#issuecomment-487088177, we allow fairly liberal implementer support signals for expanding the autofill vocabulary. So I think the main goal of the discussion here is to gather input from everyone (as this thread has been doing) to make sure the design is reasonable, even if only one browser has immediate plans to do the UI work necessary.

I think this also speaks to the question of how much work we want to do in creating more autofill tokens for more classes of addresses, e.g. Japanese addresses. The answer, IMO, is as much work as the ecosystem wants to put in. Not just browsers, either. E.g. if extensions, or AT vendors, or similar communicated that they could serve a good number of users by introducing such new autofill tokens, then I think the spec should be a reasonable clearinghouse for coordinate those efforts, and having design discussions among multiple parties to shake out any cross-cutting issues.

mnoorenberghe commented 5 years ago

Please excuse my rambling…

Do we have any evidence that the sites that currently use separate fields for these values actually require them to be separate fields? Or is it just a local preference?

@carstenhag I think we mainly need to hear from implementers to what extent they are interested in putting work into this as this would also require UI that's aware that if you change the country the address format changes. (E.g., Firefox only supports a single address field at the moment as far as I can tell.)

We show a single address-line textarea in preferences but can split it into up to 3 lines when filling. Likewise for the phone number field, we show one box but can split into many different combinations of <input> when necessary due to all the different tel-* tokens (we don't support all of them).

Another syntactic idea I had was to go with sub-attributes. Something like address-line1[street-name] and address-line1[house-number]. Would you feel different about this?

FWIW I would prefer address-line1-street-name and address-line1-house-number.

I'm guessing the reason for the square bracket syntax was to allow it to work with address-lineN with N from 1 to 3. Would you want to instead add all 6 tokens since I don't think these components are always on line 1?

Indeed. I think that's the key point, is whether there are actors in the ecosystem who would actually leverage this. It sounds like Chrome might take the steps @annevk describes (i.e., change their "user information" UI to have separate stree-name/house-number fields when you're in the given country, so that it can successfully autofill later).

The UI change is the easiest part to deal with… the harder part is being able to convert in both directions between address-lineN and the subdivisions being proposed. We dealt with a similar problem with less complexity for the different tel-* tokens and it wasn't nice… I think we still don't support all of the tel-* tokens as a result of the complexity. The reason you need to convert in both directions is because the user could have first saved that address-line as one field but needs to autofill in the separate components (and vice versa). I think it will be very hard for UAs to handle that without creating duplicates but other than somehow pushing sites to move away from these fields (unless of course they need them for shipping calculations or something like that), I don't see how we can nicely solve this problem. I'm skeptical that that Intl APIs could even be defined to do the transformations in both directions.

My main concern with this proposal is that it could make the use of these narrower fields more popular in the future even if not all UAs can handle them properly. Can we add them to the spec but mark it deprecated from the beginning? :P That would be similar to how we have https://compat.spec.whatwg.org/ where we standardize the web as it is, not as we want it (I realize this isn't a perfect analogy since sites probably aren't using these specific tokens now).

The spec already has the following text which is relevant but I'm not sure most people would notice it:

Generally, authors are encouraged to use the broader fields rather than the narrower fields, as the narrower fields tend to expose Western biases. For example, while it is common in some Western cultures to have a given name and a family name, in that order (and thus often referred to as a first name and a surname), many cultures put the family name first and the given name second, and many others simply have one name (a mononym). Having a single field is therefore more flexible.

Maybe we should expand on that and explicitly annotate which autocomplete tokens should be avoided in favour of broader ones? Also, in this case I don't think "Western biases" is applicable.

I'm very interested in hearing how other UAs plan to handle the bidirectional data transformation issue… I'm also interested in hearing arguments for why we should codify this pattern rather than leave it up to UA heuristics to figure out (which is the status quo). Why do we want to pave this cow path rather than encourage change?

P.S. I wonder if authors ever handle this by listening for insertReplacementText input events on the address-lineN field and moving the appropriate sub-components to their own fields…

JohJohan commented 3 years ago

What is the status of this ticket?

We as a company use autofill options for our forms. We use postcode combined with house number (optional house number extension) to autocomplete the street and city data. This is for dutch websites. The service for autocompleting we use is https://pro6pp.nl/en.

I would like separate attribute for house number and house number extension

nablex commented 3 years ago

It's an old and closed thread at this point but I was researching specifically address autocomplete options and came across this thread. I've also checked the linked thread and googled some more, but can't really find a better place to add my 2 cents, so I decided to add it here.

International addresses are complex in that each country or region requires their own details. However, the people living in these countries and regions generally know and expect these details.

By keeping the autocomplete options "generic", you do support the use-case where a single form has to serve a wide array of people, but you don't support the use-case where you specifically want your forms to match the expected input values for a region.

This could be to localize your form and thus appeal to the target population, it could be because your employer only works in that region and expects it to work that way or it could be because you want to validate the address according to region-specific business rules and you need structured input (as defined by that region) to do that.

We musn't forget that forms have existed for many years and region-specific details have always existed and were never an issue, but now you are basically giving developers a choice:

Neither is really the point of a specification like this. Because I can't express what I need with the specification, I'm relegated to trying to "game the system" and check browser specific implementations.

In our neck of the woods we generally ask for the street name and the street number in separate input fields. In the case of an apartment building or the like, we also need a further specification as the street number only indicates the building as a whole. The additional bit (like the floor number) can sometimes be added to the number field or it can be asked in a separate third field.

battre commented 2 years ago

We (Chrome) have reached a point where we would love to invest in extending the autocomplete attribute to better reflect the regional ways requesting address information.

I have written up an explainer document in a personal github repository: https://github.com/battre/autocomplete-attribute-explainer/tree/main

The core points are:

I'd love to hear your feedback:

smaug---- commented 2 years ago

@TGiles

galich commented 2 years ago

Hey all, sorry if this was already answered somewhere.

Do we have the list of official sources of address formats in different countries? We have a little over 200 countries on the planet, each has their official post office with their official address standards.

Something like this:

Canada Addressing guidelines USA Postal Addressing Standards

JohJohan commented 2 years ago

I found this: https://en.wikipedia.org/wiki/Address 'Format by country and area'

bojanz commented 2 years ago

Google's Address Data Service is still the main source of address format data for most libraries/packages.

howard-e commented 2 years ago

This link may also be useful to the discussion. It lists all countries and groups by similar formats. https://www.grcdi.nl/gsb/world%20address%20formats.html

battre commented 2 years ago

Thanks for all these links. I think think that they are important to double check.

On top of that, I think that a core point is to look at what websites actually request in forms and how. These guidelines don't mention that websites in some countries ask for a street name and house number in separate fields.

r12a commented 2 years ago

You should also use care when looking at "what websites actually request in forms and how", because i think you'll find plenty of sites that tried to shoe-horn things into badly internationalised frameworks, and other sites may not necessarily be following the best design principles.

Fwiw, here are a couple of reservations i have on this topic Essentially, i think that just because a percentage of addresses contain both a house number and a street name it doesn't necessarily follow that you need to split those apart on a form. Doing so introduces other problems. For example, as people mentioned above, in the place i previously lived my address began with something like this: 6, MyBuilding Name, 24a MyStreet Road. It was often problematic to know whether to put the 6 (the most important of the 2 numbers, since the building was much better signposted than the house number) in the house number field or the 24a; but whichever, it left a bunch of stuff dangling. If i put the house number, followed by the street name that would be completely different from the way i'd normally write my address. If i put the flat number, then building name, and put the house number + street name on another line, i'd be worried in case the house number was mistaken (as at least once, when we had mail sent to no. 6 on our street). It was much easier if there were a couple of lines available, which both autofilled, and i could fill them as i wanted. There are also plenty of addresses where a house number isn't relevant. In both of these use cases, a simple general field that can be filled in (an autoprompted) by the user as they prefer makes life easier. It also makes it easier to localise the layout of form fields: for example, the house number comes after the street name in Switzerland. Separating house number and street name into different fields then causes extra work for localisation of the UI, whereas simple line fields allow the user to type in whatever order or details they need. Adding this separation may also encourage more UI designers to think that they perhaps should be separating the fields, if there's functionality behind it.

So my worry is that rather than being helpful, this may turn out to be overprescriptive because a better design pattern for UIs would be to not separate out the house number.

Btw, fwiw, typing in your house number seems to be increasingly uncommon in the UK these days, when ordering things online. You generally type in your postcode, and then select the house number and street from a popup list.

TGiles commented 2 years ago

I keep flipping back and forth between "This is a good idea" and "This is trying to solve the wrong problem". Making autocomplete better is something I want to see, but I guess I'm confused about this proposal. It sounds like street-address should be able to cover house-number, apartment-number, etc, already but is not due to forms that specify too many fields or too specific fields; please correct me if I'm wrong though. It does seem like this extension to the spec may help given the metrics in the explainer doc, but I wonder if there's a better way.

The last two bullet points of the "Implementation by browser" section in the explainer document would be something worth exploring I think. I don't think we'll be able to keep pace with all the different conventions and styles of addresses in the world, but if the browsers can learn what data should be filled or how this data should be associated...I think that's something that would be extremely beneficial. Learning how to autocomplete where the user is, that's the endgame in my opinion. Has any one else thought of something like this?

Barring that local learning part, extending the street-address might be a good enough solution. I do want to second mnoorenberghe's concern of, "My main concern with this proposal is that it could make the use of these narrower fields more popular in the future even if not all UAs can handle them properly". I guess knowing more about why websites are using such narrow fields would be beneficial for me (and maybe I've missed that in this thread, feel free to point me in the right direction. I do see nablex's point though.) because again, it sounds like street-address already covers the house-number, apartment-number case.

nablex commented 2 years ago

I've read through the proposal and it seems to address all my prior concerns so I would love to see it implemented!

I think it's important to stress this part:

They choose to use these formats despite a lack of support by the autocomplete attribute, so we don’t expect that nudging website authors towards an address representation with address-line1, 2, 3, is likely to succeed

Adresses go far beyond websites and browser-based autocomplete, those local preferences are ingrained in the software already running in any given corporation, from CRMs to ERPs to custom solutions. They are reinforced every time a new application is built that needs to integrate with those existing systems. Not offering an autocomplete feature does not change this reality, it just makes it harder for developers to deal with it.

As a developer, I have spent more time actively disabling or circumventing autocomplete than using it. As a user I have been frustrated time and again as the autocomplete gets it wrong, requiring me to manually correct the form fields anyway.

I don't really see the downside to enabling more granular autocomplete options, there seem to be two possibilities:

I hope this addresses the repeated concern:

My main concern with this proposal is that it could make the use of these narrower fields more popular in the future even if not all UAs can handle them properly

The key takeaway is: they are already popular because they are necessary.

battre commented 2 years ago

Apologies for the radio silence while I was gathering more data.

To address the question "I guess knowing more about why websites are using such narrow fields would be beneficial for me" here is one answer that I got from a major German company (we reached out to some companies and await more responses):

There are several answers and reasons for this, we´ll have to keep in mind, that the decision to separate these fields isn´t always made consciously, often historically inherited.

Some reasons belong to database design; where street names are CHAR, and house numbers are NUM and VARCHAR was expensive or unavailable

Some reasons belong to requirements of the printer programs for printing the address labels: these required the separation described

I also learned that the metrics presented in the explainer document are an underrepresentation. We found more examples of real websites that ask require a more structured representation and I think that some of these are not reflected in the numbers, yet. For example:

The very generic catch-all items ("Informazioni aggiuntive (interno, scala...)" = "Additional information (interior, staircase ...)"; "Complemento (opcional) Apartamento, sala, conjunto, edificio, andar, etc." = "Complement (optional) Apartment, room, set, building, walk") may require some further tuning in the proposal.

r12a commented 2 years ago

Some reasons belong to database design; where street names are CHAR, and house numbers are NUM and VARCHAR was expensive or unavailable

There's an example of a pattern we probably don't want to prolong the life of, since i assume that if i type in a house number such as 25a (a format i have had for more than one place i lived), things will break. Also, what about 8-12 My Street?

We found more examples of real websites that ask require a more structured representation and I think that some of these are not reflected in the numbers, yet.

It would be good to also gather data from some non-Latin script languages and those that are not of European origin. Japanese and Chinese would be a good start. See the example at https://en.wikipedia.org/wiki/Address#Japan, where the line 東京都文京区白山4丁目3番2号 includes country name, (prefecture name), city name, ward and decreasing subdivision names. Note the absence of a street name. I think a common form format for inputting Japanese addresses is likely to ask for the user to type 4-3-2 where we would have just a house number.

That page has informal data on address formats for around 65 countries.

himorin commented 2 years ago

For address in Japan, government agency has started gathering all addresses as base registry (only in Japanese) and sorting out complex points. These work has just started from last year, and data registry has not been in complete. As an image used in a main page for the base registry, there are mainly two types of format after ward (see a bit more detail at p9 of brief overview of the registry - PDF), and it's common to input followings into one (or two - until building and put building name and house number) as @r12a pointed. Also, such simple input form is preferred for two reasons. First, there are many special cases exists, such that some small number of cities use street based address, temporal address for short time (like a few ten years) in some readjustment area has a second ward name (actually, my current address is something like AAA prefecture BBB city <ward name 1> CC-DD <ward name 2> EE-FF <building name> GGGG). Second, most of individual ward has its own postal code (7 digits), and a good point for division (東京都文京区白山 in Richard's example).

zcorpan commented 2 years ago

@mfreed7 any update here? :)

Mason will ensure the updated proposal is posted in the issue.

https://github.com/whatwg/html/issues/7981#issuecomment-1179127723

battre commented 2 years ago

I can share a brief update: This is not forgotten. I am currently taking another pass on top ecommerce sites (as per ecommercedb.com) for a number of countries. After that, I will update the explainer doc with the results and draft a pull request to the spec.

battre commented 2 years ago

Here is another short update: I have looked at the address form structures of real world websites in 23 countries: https://github.com/battre/autocomplete-attribute-explainer/blob/main/country_analysis.md

I found this very enlightening but plan to re-do some of the work to convert this into a more machine processable format. I need to wrap my mind more around the question whether we can build an all encompassing solution or whether we need to build country specific solutions.

One observation/confirmation is that the autocomplete attribute does not work well for many countries.

Another observation is that there are a lot of snowflakes. E.g. in Hungary many websites split the name of a street (e.g. "Amphitheatre") from the type of the street ("Parkway", "Avenue", ...) into separate fields. If this is what delivery services ask for, I can see why websites implement it. But in this case today's autocomplete won't work. I am also convinced that this is a feature that we don't want to offer users in all countries.

I am currently thinking of having a machine readable catalog of address structures in different countries that could be shared across browsers. This catalog could contain a list of fields that are commonly used in different countries (this allows browsers to render address forms that meet the structures of countries and are more fine grained than what libaddressinput offers). The catalog could also contain rules for combining fields (in some countries you write "${street name} ${house number}" and in others "${house number} ${street name}"). If browsers agree on a set of rules, we could tell website authors which combinations can be filled on their site and which ones cannot.

Anyways... I am not dead and still exploring....

mfreed7 commented 2 years ago

I've added Agenda+ for this - we'd like to bring it back for a bit more discussion. @past, could we please get this on the agenda for the Oct 27 meeting (skipping the Oct 13 meeting)?

mfreed7 commented 1 year ago

Agenda+ to just gently ping the request for implementer points of contact to participate in a half-day autocomplete attribute workshop.

smaug---- commented 1 year ago

@galich

annevk commented 1 year ago

In principle we're interested in this. Please keep me in the loop. I'll also file some issues on the repository.

battre commented 1 year ago

Great! For planning purposes: Would you be interested in joining a 1/2 day workshop to discuss this in person and go a bit deeper?

annevk commented 1 year ago

I may or may not be the person that participates, but I'm the person you want to keep in the loop as you go about organizing it. 😊

mathias22osterhagen22 commented 1 year ago

@mnoorenberghe

Do we have any evidence that the sites that currently use separate fields for these values actually require them to be separate fields? Or is it just a local preference?

Yes. By example for third party website it's necessary to send the number of the street separately (like sumsub). For banking purpose as well, better to keep each part of the address distinctly to easier screening processes.

romane-echino commented 1 year ago

If I can add something to the fact that street-name and house-number should be separated and that end-users should now slowely take that habit is because of the new international standard ISO 20022 about payment standards.

That standard has been voted in Europe and currently in production in Switzerland. One part of that new standard is the QR-Invoice (only in switzerland atm) which contains all payment informations inside a 2d qr code. In the documentation the house-number is on another line than the street-name. It was a lot of pain for invoicing software (like us) to translate every address field to two field (I mean regexp doesn't cover 100% of the cases since people write addresses in so many ways...).

battre commented 1 year ago

Thanks for sharing! Are there any other fields that ISO 20022 wants to treat specially? Apartment/Unit numbers? Floors? Staircases? Entrances? How do they deal with countries that rely on building names?

battre commented 1 year ago

Is it this?

    <xs:complexType name="PostalAddress24">
        <xs:sequence>
            <xs:element maxOccurs="1" minOccurs="0" name="AdrTp" type="AddressType3Choice"/>
            <xs:element maxOccurs="1" minOccurs="0" name="Dept" type="Max70Text"/>
            <xs:element maxOccurs="1" minOccurs="0" name="SubDept" type="Max70Text"/>
            <xs:element maxOccurs="1" minOccurs="0" name="StrtNm" type="Max70Text"/>
            <xs:element maxOccurs="1" minOccurs="0" name="BldgNb" type="Max16Text"/>
            <xs:element maxOccurs="1" minOccurs="0" name="BldgNm" type="Max35Text"/>
            <xs:element maxOccurs="1" minOccurs="0" name="Flr" type="Max70Text"/>
            <xs:element maxOccurs="1" minOccurs="0" name="PstBx" type="Max16Text"/>
            <xs:element maxOccurs="1" minOccurs="0" name="Room" type="Max70Text"/>
            <xs:element maxOccurs="1" minOccurs="0" name="PstCd" type="Max16Text"/>
            <xs:element maxOccurs="1" minOccurs="0" name="TwnNm" type="Max35Text"/>
            <xs:element maxOccurs="1" minOccurs="0" name="TwnLctnNm" type="Max35Text"/>
            <xs:element maxOccurs="1" minOccurs="0" name="DstrctNm" type="Max35Text"/>
            <xs:element maxOccurs="1" minOccurs="0" name="CtrySubDvsn" type="Max35Text"/>
            <xs:element maxOccurs="1" minOccurs="0" name="Ctry" type="CountryCode"/>
            <xs:element maxOccurs="7" minOccurs="0" name="AdrLine" type="Max70Text"/>
        </xs:sequence>
    </xs:complexType>

(Found on https://www.iso20022.org/iso-20022-message-definitions?business-domain=1 in "Payments Mandates")

romane-echino commented 1 year ago

@battre Yep that's exactly it! How fast 😄 I'm not an expert in that new standard so... for now... I don't see any other major problem. But as usual future is gonna prove me wrong 😄

Here is some documentation derived from the ISO 20022 standard for switzerland :

Element Example: Structured Example: Combined Remarks
Address type “S” “K” “S” - Structured address “K” - Combined address
Name Pia-Maria RutschmannSchnyder Pia-Maria RutschmannSchnyder
Street or address line 1 Grosse Marktgasse Grosse Marktgasse 28 “S” - Street/P.O. Box “K” - Street and building number of P.O. Box
Building number or address line 2 28 9400 Rorschach “S” - Building number “K” - Postal code and town
Postal code 9400 “S” - Postal code “K” - Do not fill in
Town Rorschach “S” – Town “K” - Do not fill in
Country CH CH

Found on https://www.paymentstandards.ch/dam/downloads/ig-qr-bill-en.pdf in "4.3.1 Use of address information"

Some of our banks only support the Structured address standard and because of that it has to be separated

battre commented 1 year ago

I am organizing a virtual workshop on the topic of improving the autocomplete attribute.

Date: January 17, 2023 Time: 7 AM - 9 AM PT (US West Coast), 4 PM - 6 PM GMT+1 (Germany), 9 PM - 11 PM GMT+5:30 (India)

The purpose of this workshop is to

It should serve as a foundation for creating a workstream on this topic afterwards.

If anybody would like to be invited, please email me at battre@google.com with a one sentence summary of your affiliation and why you are interested in joining.

battre commented 1 year ago

A big thank you to all the participants.

The meetings notes can be found here.

If you would like to contribute to this topic in the next weeks, please register here. I would like to set up a bi-weekly meeting to make progress in this space.

r12a commented 1 year ago

FWIW [ In the workshop report international name changes were mentioned a few times. I got the impression that that is not a focus of the work here, so i mention this only in passing – but since it came up a few times i thought i should note that the issues with capturing, storing, and presenting personal names are much bigger than the problem with Hispanic family names. If you want a glimpse of some additional aspects to consider see Personal names around the world. ]

momdo commented 1 year ago

FYI:

While @himorin refers to Japanese government documents (https://github.com/whatwg/html/issues/4986#issuecomment-1123239298), GIF DS-442 (Government Interoperability Framework - 442 "コアデータパーツ 住所（アドレス）") is available on GitHub from the Digital Agency. https://github.com/JDA-DM/GIF/blob/main/440_%E3%82%B3%E3%82%A2%E3%83%87%E3%83%BC%E3%82%BF%E3%83%91%E3%83%BC%E3%83%84/md/442_core_dataparts_address.md

This diagram provides an overview of Japanese addresses structure: https://github.com/JDA-DM/GIF/blob/main/440_%E3%82%B3%E3%82%A2%E3%83%87%E3%83%BC%E3%82%BF%E3%83%91%E3%83%BC%E3%83%84/md/442/media/image1.png

battre commented 1 year ago

I have proposed some fundamental principles for how we could move forward for this here: https://github.com/battre/autocomplete-attribute-explainer/

I would appreciate feedback (either here or in the issues I have created for the individual sections).