bump to f2f

Matthew: the UI for suggestions already exists.

Tess: this is giving the page the ability to opt in or out depending on where in the page. Cynicism aside, this is a good idea we should do it. Similar scenario with different input methods. If you have a complex IME it may or may not interact with the page well. The page may provide its own IME, which might be more specialised. The values of on or off are not good. Feels like it should be boolean. THe downside would be there's no explicit opt out in that case. It's presence or absence. If it were boolean you couldn't be saying outright don't do, only defnitely do it. If the default is do it there's no way to turn it off

Amy: would there be other values in the future?

Matthew: like system default. Could this turn into a an attribute with a list of values? Like 'on' and the subject area is...

Tess: i think this design is roughly right, and there are use cases that aren't LLMs, existing use cases for autocomplete etc

Matthew: if we're saying subject domain should be a different attribute, is writing suggestions the right name for the one we've got?

Tess: I don't think we need to bikeshed that. They talk about calling it text prediction instead of writing suggestions, but that's too narrow. I don't have a better suggestion.

Matthew: also, we've talked about IMEs and i18n issues, should we ask them? For example how does it know what language the writing suggestions are going to be in? We have a lang attribute, how does that interact with custom elements?

Tess: it works fine, it's already well specified. The system at the OS level either there's some kind of keyboard or input method selection, and your language preference, the system has a really good guess. The page can use lang attributes to help that along. All of that is able to be fed into the thing that decides what to do. Do we need a separate predictive-lang? Probably not

Matthew: not asking that. Do we think we should run it past i18n

Tess: I'll write a comment. Also remind them to talk to i18n.

Amy: is it just to control llm provided suggestions or are there other options?

Tess: other options. Eg. in iOS it can suggest next words. BUt what they're actually doing is using an LLM

Amy: their solution is good, our reality is bad

Lea: Is this only on contenteditable?

Tess: no, all form controls

Matthew: what if in future they want to fine grain control it - so autocomplete or predictive text as we know it is differentiated from gpt style stuff?

Tess: right, like you said if you want to drop a hint for domain expertise. If we need additional controls we can add additional elements

Matthew: originally I thought ths has a11y considerations, but actually it doesn't because the browser is already shipping controls for this. But those are all for single or few word things. But if you could actually invite a whole paragraph or essay, there isn't a control that exists to do that.

Dan: sounds fine

Lea: is the idea that authors will opt into this, or that they will opt out?

Tess: both. Browsers might have it on for some areas and some off

Amy: so it's up to the browsers

Sanghwan: implementer defined, gives authors control over it. Better than now

Tess: scenario is the samea s disabling the system IME, maybe the site itself is doing it

Matthew: there is not a widget in OSs and browsers which would allow you to pick a writing assistant result

Tess: I wouldn't say that

Matthew: in that case maybe there are accessibility considerations. If this could be used to control the variety of different types of writing assistants, don't we want to say the user should be given that control? OS or browser setting

Tess: the attribute is a hint. the page is saying I'm doing something such that the system feature, if present, would interfer with the function of the page. It's just a hint. THe UA could decide to do it anyway, for the user.

Matthew: we can't tell the ua what options to have, but don't we want to use this opportunity to suggest the ua affords the user that choice? I want all these forms of autocompletion, except that one. Is that something we should suggest they consider including?

Tess: we could try to say something, but worried about giving advice that makes it less likely that their PR lands. Might be reluctance to add advice about user interfaces.

Sangwhan: and might be a much larger change to do it right.

Tess: you end up with a potential explosion of the site wanting to say these but not this one, and the user the same.. gets hairy. The opt out is probably sufficient.

Tess: drafts closing comment

Hi @sanketj!

@matatk, @rhiaro, and I took a look at this during a breakout at the TAG F2F today, and we're overall supportive of where you've ended up with the proposal. Have you run this by the i18n folk? We suspect they'll have relevant thoughts.

Thanks for bringing this to us. Please don't hesitate to ask us to take another look should things substantively change.

Incidentally, we asked Google Bard to draft a supportive closing comment for us and here's what it came up with:

**Strong support for writingsuggestions! Granular control & user/developer focus are excellent. Looking forward to implementation! @sanketj **