06:30:17 <RRSAgent> RRSAgent has joined #autofill-dynamic
06:30:21 <RRSAgent> logging to https://www.w3.org/2025/11/13-autofill-dynamic-irc
06:30:21 <breakout-bot> RRSAgent, do not leave
06:30:22 <breakout-bot> RRSAgent, this meeting spans midnight
06:30:22 <breakout-bot> RRSAgent, make logs public
06:30:24 <breakout-bot> Meeting: Autofill for dynamically changing forms
06:30:24 <breakout-bot> Chair: Stephen McGruer, Yoav Weiss
06:30:24 <breakout-bot> Agenda: https://github.com/w3c/tpac2025-breakouts/issues/89
06:30:24 <Zakim> Zakim has joined #autofill-dynamic
06:30:25 <breakout-bot> Zakim, clear agenda
06:30:25 <Zakim> agenda cleared
06:30:25 <breakout-bot> Zakim, agenda+ Pick a scribe
06:30:27 <Zakim> agendum 1 added
06:30:27 <breakout-bot> Zakim, agenda+ Reminders: code of conduct, health policies, recorded session policy
06:30:27 <Zakim> agendum 2 added
06:30:27 <breakout-bot> Zakim, agenda+ Goal of this session
06:30:28 <Zakim> agendum 3 added
06:30:28 <breakout-bot> Zakim, agenda+ Discussion
06:30:28 <Zakim> agendum 4 added
06:30:28 <breakout-bot> Zakim, agenda+ Next steps / where discussion continues
06:30:29 <Zakim> agendum 5 added
06:30:29 <breakout-bot> Zakim, agenda+ Adjourn / Use IRC command: Zakim, end meeting
06:30:29 <Zakim> agendum 6 added
06:30:30 <breakout-bot> breakout-bot has left #autofill-dynamic
08:02:31 <yoav> yoav has joined #autofill-dynamic
08:03:31 <stephen_mcgruer> stephen_mcgruer has joined #autofill-dynamic
08:03:35 <stephen_mcgruer> q?
08:03:40 <stephen_mcgruer> scribe+
08:03:41 <stephen_mcgruer> present+
08:03:45 <lychee> lychee has joined #autofill-dynamic
08:05:11 <stephen_mcgruer> present+ yoav
08:05:14 <stephen_mcgruer> present+ lychee
08:05:22 <stephen_mcgruer> yoav: This is a proposal we talked about during last years TPAC
08:05:24 <stephen_mcgruer> ... a few things happened since
08:05:32 <stephen_mcgruer> ... being prototyped in Chromium, but hasn't landed yet
08:05:44 <stephen_mcgruer> [Proposal - https://github.com/WICG/address-autofill]
08:05:50 <stephen_mcgruer> yoav: Autofill is awesome
08:06:13 <stephen_mcgruer> ... Shopify stats say great things about autofill - 1/3rd of guest checkouts use autofill, and have a 41% increase in completion rate
08:06:20 <stephen_mcgruer> ... Good from our perspective, also good for user
08:06:30 <stephen_mcgruer> ... At the same time, current autofill model is aimed at static forms
08:06:44 <stephen_mcgruer> ... particularly for addresses, this is not how things work in real life
08:06:45 <stephen_mcgruer> ... different countries have different address structures and requirements
08:07:00 <stephen_mcgruer> ... so people use hidden form fields in order to get ALL the possible required data, then reshuffle the form in DOM and show the user
08:07:10 <stephen_mcgruer> ... This is bad for the merchant from a complexity perspective
08:07:25 <stephen_mcgruer> ... This is bad for a user because hidden forms are hidden and they aren't aware of what has been filled until its done
08:07:48 <stephen_mcgruer> yoav: Shopify came up with a proposal to help solve this
08:07:56 <stephen_mcgruer> ... an Autofill event that fires after autofill has happened
08:08:03 <stephen_mcgruer> ... event gets passed autofill values (may not be needed?)
08:08:25 <stephen_mcgruer> ... and a refill promise, that when resolved, taking in account users permission/settings
08:08:28 <stephen_mcgruer> ... will then re-fill the new fields
08:08:38 <stephen_mcgruer> [Yoav shows example script]
08:09:00 <stephen_mcgruer> yoav: The reshuffling could be sync or async, depending on page structure, server side rendering, etc
08:09:14 <stephen_mcgruer> ... We also wanted to discuss a 'full-address' autocomplete attribute value on the form
08:09:30 <stephen_mcgruer> ... Not currently needed for Chrome based on its Autofill security model, but maybe needed for other browsers?
08:09:43 <stephen_mcgruer> ... The question is, without this attribute, how does the browser know what to show the user?
08:09:54 <stephen_mcgruer> ... We want the user to give knowing consent to what will be filled
08:10:00 <stephen_mcgruer> ... We're not very sure about this, would love feedback
08:10:32 <stephen_mcgruer> yoav: Once this all happens, and is in the wild for long enough, maybe browsers could deprecate autofilling of hidden fields, which would be more private for users
08:10:38 <stephen_mcgruer> yoav: Open questions:
08:11:03 <stephen_mcgruer> ... 1. Do we need the autofill_values in the event at all? This was from original proposal which was sync BEFORE autofill, now its async AFTER autofill, so you can just refill the form
08:11:39 <stephen_mcgruer> ... 2. How would browser extensions that provide autofill-like facilities deal with this mode? Just haven't thought about it.
08:12:10 <stephen_mcgruer> christian: I'm glad the second open question is here
08:12:32 <stephen_mcgruer> ... if there's a more-structured way for the autofill data to be accessed by the webpage, is direct DOM manipulation still useful?
08:12:55 <stephen_mcgruer> ... what if we just give the site the data in some structured template
08:13:19 <stephen_mcgruer> ... always been a hit and miss for all browsers for filling certain forms, conflicting with things like key events and so on
08:14:43 <stephen_mcgruer> yoav: We heard objections from Chrome team that they want to show the user that certain data was autofilled, and paint it in certain ways
08:14:45 <stephen_mcgruer> stephen_mcgruer: +1
08:14:59 <stephen_mcgruer> ???: Autofill is magic, its incredible, we ask developers to do basically no work, and we save humanity a billion hours a day
08:15:04 <stephen_mcgruer> s/???/ricky/
08:15:19 <stephen_mcgruer> ricky: I used to maintain safari's heuristics for autofill in a past life, nowadays I work on authentication
08:15:57 <stephen_mcgruer> ... In safari, my recollection is that we decided that when a form asked for *anything* related to address, and user was doing a one-shot autofill, our UI would show everything - even things that weren't being filled
08:16:06 <stephen_mcgruer> ... After we're done filling, we wait a beat and re-process, and re-fill out
08:16:17 <stephen_mcgruer> ... It's not great. It would be good to know when the work is done
08:16:50 <stephen_mcgruer> (get clarification on what the current proposal)
08:16:54 <stephen_mcgruer> ricky: That seems reasonable
08:17:14 <stephen_mcgruer> ... One thing I do have battle scars from is websites thinking they should fight autofill
08:17:39 <stephen_mcgruer> yoav: Yep. From my perspective, the repo is titled address autofill. Primarily from feedback of this exact same scenario
08:17:48 <stephen_mcgruer> ... I'm only interested in addresses, maybe we should call the event address autofill?
08:19:04 <stephen_mcgruer> [We briefly touch on autocomplete=off]
08:19:13 <stephen_mcgruer> ricky: I don't think anyone listens to that in password anymore
08:19:23 <stephen_mcgruer> ... in non-password cases, some user agents listen to it in certain cases
08:19:32 <stephen_mcgruer> ... that's where we're all at?
08:19:35 <stephen_mcgruer> [Yes, generally]
08:20:14 <stephen_mcgruer> stephen_mcgruer: Just wanted to ack that we also have automatic refill in Chrome
08:20:21 <stephen_mcgruer> ricky: Scoping this to not all autofill but certain kinds does seem interesting
08:21:07 <stephen_mcgruer> ricky: For the attribute that can express that the form may change dynamically , that sounds good. More metadata, lets you do better UX
08:22:25 <stephen_mcgruer> ricky: For hidden fields, I think safari doesn't do it
08:22:43 <stephen_mcgruer> ???: For [lastpass? onepass? sorry I missed it], I don't think we fill hidden fields either
08:23:08 <stephen_mcgruer> ???2: (Describes a scenario where iframe across origins goes wrong)
08:23:50 <stephen_mcgruer> lychee: I can attest to that. For Meta IAB, we ran an experiment where we took Chromium's ability to detect hidden fields and ran an experiment [scribe missed details]
08:24:07 <stephen_mcgruer> ... we found that there's a gazillion ways to hide a field
08:24:08 <stephen_mcgruer> ricky: +1
08:24:41 <stephen_mcgruer> lychee: We actually did this to solve a shopify issue, where each iframe has a separate fields and so we would have a visual indicator
08:25:19 <stephen_mcgruer> stephen_mcgruer: Should we start an autofill CG?
08:25:33 <stephen_mcgruer> (This was a joke, but the room says "yes" across four different autofill implementations!)
08:26:33 <stephen_mcgruer> yoav: So I'm hearing support for address autofil
08:26:39 <stephen_mcgruer> ... would credit card autofill look similar
08:26:51 <stephen_mcgruer> ... the whole multiple frame problem is also interesting here
08:26:54 <stephen_mcgruer> .. the event would fire on each one
08:27:11 <stephen_mcgruer> ... that might be hard to implement on the browser side?
08:28:06 <stephen_mcgruer> stephen_mcgruer: I do have some concerns
08:28:23 <stephen_mcgruer> (we discuss what happens if multiple refill calls happen - wait for the last? how?!)
08:28:31 <stephen_mcgruer> ???1: How would this work across iframes?
08:28:53 <stephen_mcgruer> yoav: I think fires on each iframe, each one does some update, they coordinate?  Or they each resolve the promise? And if they each resolve, then when do we do the refill.
08:28:58 <stephen_mcgruer> ... Definitely an open question!
08:29:12 <stephen_mcgruer> ricky: Take the common frame ancestor and dispatch autofill on that one
08:29:34 <stephen_mcgruer> ricky: parent frame is coordinating the inner frames? Or are they sandboxed?
08:29:43 <stephen_mcgruer> yoav: May be sandboxed, but they have to send that information somehow
08:30:03 <stephen_mcgruer> yoav: I don 't know how common multiple-iframe is for address forms
08:30:13 <stephen_mcgruer> lychee: Billing address tends to be in an iframe
08:30:27 <stephen_mcgruer> ... I have seen sites where shipping address is in the main frame, but then everything billing address is in the iframne
08:31:24 <stephen_mcgruer> stephen_mcgruer: So all in the same iframe, that sok
08:31:30 <stephen_mcgruer> lychee: But we may want to fill both shipping and billing
08:31:41 <stephen_mcgruer> stephen_mcgruer: One hard thing btw is "what is an address" to each autofill implementor
08:32:57 <stephen_mcgruer> ricky: We should game theory out the 'other things on the page can listen to this', but I think its fine
08:33:44 <stephen_mcgruer> ricky: For the third item about one day not filling hidden fields. Thats at the autofill implementors discretion
08:33:58 <stephen_mcgruer> ... I think its a bit different
08:34:13 <stephen_mcgruer> yoav: This is here, because we thought all browsers are autofilling (known) hidden fields, which is problematic
08:34:20 <stephen_mcgruer> ... definitely not required
08:37:35 <stephen_mcgruer> yoav: So overall I'm hearing yes, we need an autofill CG, and this proposal sounds worthwhile to people?
08:37:36 <stephen_mcgruer> (Assent)
08:38:34 <stephen_mcgruer> (With the general expectation to propose changes that would end up in WHATWG probably?)
08:38:46 <stephen_mcgruer> yoav: Implementation-specific question for Safari - how much Autofill is in WEbKit?
08:38:51 <stephen_mcgruer> ricky: Very little
08:39:03 <stephen_mcgruer> ???3: With a slightly growing amount, but still not a lot
08:39:14 <stephen_mcgruer> yoav: I'm interested in the hooks to implement this programmatic refill
08:39:25 <stephen_mcgruer> ... how much of this could I help write?
08:39:36 <stephen_mcgruer> ricky: In safari's case, not implementable in webkit
08:39:39 <stephen_mcgruer> ???3: It could be
08:40:44 <stephen_mcgruer> ricky: if you have a bug report for automatic refill not working in Safari btw, please do file it. Happy to look at it
08:40:54 <stephen_mcgruer> yoav: Related work - we had a parallel stream that looked at testdriver for uatofill
08:41:09 <stephen_mcgruer> ... we wanted to have fake WPTs to reproduce where we hit snags across different implementations
08:41:15 <stephen_mcgruer> ... waiting on implementor interest
08:42:25 <stephen_mcgruer> ricky: I will come back on that
08:42:48 <stephen_mcgruer> lychee: On the open questions - do we need autofill_values? I don't have an opinion. Yoav may be the best to answer?
08:42:54 <stephen_mcgruer> yoav: I agree, probably more of a developer question
08:43:03 <stephen_mcgruer> ... will come back with an answer
08:43:39 <stephen_mcgruer> lychee: For autofill_values, were you thinking the values that had been filled in, or the full address autofill values?
08:43:45 <stephen_mcgruer> yoav: The values that are already filled in?
08:44:26 <stephen_mcgruer> stephen_mcgruer: Do you want the values we *tried* to fill in, or the values that were filled?
08:44:47 <stephen_mcgruer> ricky: This gets close to doing a full schema again, re requestAutocomplete
08:44:51 <stephen_mcgruer> yoav: Yes, full schema not in scope
08:45:03 <stephen_mcgruer> ... What we did for the prototype, was play back the form in JSON format for the event, but that was when it was BEFORE fill
08:45:34 <stephen_mcgruer> yoav: I think we should drop it unless we have a use case
08:45:53 <stephen_mcgruer> ricky: I suspect you can skip user preference part under hidden fields
08:46:00 <stephen_mcgruer> yoav: Yeah, need to rewrite that part
08:46:27 <stephen_mcgruer> lychee: Sounds like (3) is a nice north start that we won't hit practically
08:46:33 <stephen_mcgruer> yoav: Yeah, lets make it long term aspirational and non-commital
08:46:43 <stephen_mcgruer> schwering: I have a few questions related to hidden fields
08:46:54 <stephen_mcgruer> ... Are you proposing to make this address specific?
08:47:03 <stephen_mcgruer> ... When we relate this to hidden fields, what about all the other types we may fill
08:47:13 <stephen_mcgruer> ... Wouldn't it be unfair to say we stop filling hidden fields?
08:48:18 <stephen_mcgruer> stephen_mcgruer: So hidden fields are definitely not in scope
08:48:33 <stephen_mcgruer> ... for the address specific, I think we should name the event generic and then only fire it for what the implementor thinks is good
08:48:44 <stephen_mcgruer> yoav: What if we later figure out that creditcard event has to be a specific subtype
08:48:58 <lychee> lychee has joined #autofill-dynamic
08:49:39 <stephen_mcgruer> ???2:  I like the idea of using options, because its easier to forward-deploy it for websites, as opposed to having to write generic code from day 1
08:50:51 <stephen_mcgruer> yoav: Options at event listener to listen to a specific type?
08:50:55 <stephen_mcgruer> ricky: That kind of narrowing down is dangerous
08:51:08 <stephen_mcgruer> ... you can introspect your own form to see what tpye it was? Is that good enough vs the weight of a contract
08:51:38 <stephen_mcgruer> (we discuss all the groups writing down what they think an address is :D)
08:51:53 <stephen_mcgruer> ???1: There is literature that exists for defining what an address is out there, which is relatively recent...
08:52:55 <stephen_mcgruer> (stephen_mcgruer describes Chrome's address type)
08:53:11 <stephen_mcgruer> (???1 describes 1pass's giant text blob that they introspect!)
08:53:21 <stephen_mcgruer> (lychee describe's meta representation - similar)
08:53:31 <stephen_mcgruer> s/similar/similar to Chrome/
08:54:16 <stephen_mcgruer> yoav: This has been great, great feedback
08:54:26 <stephen_mcgruer> ... I feel setting up a CG to talk about this and potentially other autofill things feels like a good direction
08:54:31 <stephen_mcgruer> ... thank you everyone!
08:54:41 <stephen_mcgruer> yoav: This proposal is in WICG
08:54:47 <stephen_mcgruer> https://github.com/WICG/address-autofill
08:54:58 <stephen_mcgruer> ... Please file issues! I will polish it up, this is my focus until end of year.
08:56:39 <stephen_mcgruer> RRSAgent: make minutes
08:56:40 <RRSAgent> I have made the request to generate https://www.w3.org/2025/11/13-autofill-dynamic-minutes.html stephen_mcgruer
13:34:15 <tidoust> tidoust has joined #autofill-dynamic
13:34:46 <tidoust> RRSAgent, bye
13:34:46 <RRSAgent> I see no action items