Add a new attribute called `writingsuggestions` to control UA-provided writing assistance

[sanketj]

This PR proposes the addition of a new attribute called writingsuggestions to control UA-provided writing assistance, addressing #9065. Some browsers provide this capability to users (see https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/WritingSuggestions/explainer.md#use-case) but there are scenarios in which developers may want to turn off browser provided writing assistance, such as writing extensions like Grammarly or sites providing their own solutions. This new attribute will have values "on" and "off", and each element will have a default behavior as determined by the UA. This attribute's state is also inheritable from ancestor elements.

• [X] At least two implementers are interested (and none opposed):
  • Edge/Chrome
  • Safari
• [X] Tests are written and can be reviewed and commented upon at:
  • https://github.com/web-platform-tests/wpt/pull/43780
• [X] Implementation bugs are filed:
  • Chromium: https://bugs.chromium.org/p/chromium/issues/detail?id=1513953
  • Gecko: https://bugzilla.mozilla.org/show_bug.cgi?id=1871621
  • WebKit: https://bugs.webkit.org/show_bug.cgi?id=266824
• [X] MDN issue is filed: https://github.com/mdn/mdn/issues/502
• [X] The top of this comment includes a clear commit message to use.

---

/acknowledgements.html ( diff ) /dom.html ( diff ) /index.html ( diff ) /indices.html ( diff ) /interaction.html ( diff )

[sanketj]

Thanks for working on this @sanketj! really great to see it coming along. Left a bunch of suggestion. Looking forward to next round of review.

Thanks for the great feedback @marcoscaceres! I've addressed your comments, let me know what you think about the latest version.

[dandclark]

Hi @marcoscaceres, @sanketj is on leave for the next few weeks so I'll be trying to move this forward in his absence.

I've pushed changes to address your latest feedback. Since it's not my PR GitHub wouldn't let me auto-commit your suggestions or close out the opened issues, so when you get a chance please take a look and close those out if you're happy with the changes.

[marcoscaceres]

Yeah, it's not letting me acknowledge them as addressed either, but all looks good to me.

Can we get this merged (maybe @domenic)?

[domenic]

This still needs editor review. There's been a lot of back-and-forth on it, so I guess now it's ready? We'll put it in the review queue then!

[dandclark]

Yes, I believe it's ready. Thanks @domenic!

[dandclark]

Thanks @domenic for the review! I think I've addressed all the feedback here, so please take another look when you get a chance.

[dandclark]

Thanks @domenic! Addressed the latest round of feedback.

[dandclark]

Thanks @domenic! Addressed latest round.

[dandclark]

@annevk and @domenic, I went ahead and added Telephone to the list of valid input types for writingsuggestions in this PR based on comments here: [1], [2].

@annevk, do you have thoughts on my answer here regarding the attribute not returning different values for elements that don't support writing suggestions? I’d like to try to come to a decision on this one way or another to unblock this spec.

[annevk]

@dandclark if as you say implementations can do whatever and none of it is exposed to script, how is any of it actually relevant?

[dandclark]

@annevk That section is an attempt to follow the example of spellcheck, which has a similar section ("User agents must only consider the following pieces of text as checkable for the purposes of this feature..."). It describes which kinds of elements should be spell-checkable by user agents, but those details are not exposed directly to script/HTML.

I think the purpose of having a section like this for spellcheck and writingSuggestions is to give authors an idea of the widest possible set of elements that user agents might apply those features to. However, an alternative approach could be to replace it with a non-normative note that describes more generally the types of places wshere user agents might apply the feature, i.e. anywhere there's editable text. I could make that change for the writingSuggestions if you think it would be preferable.

[annevk]

Spellchecking also has the concept of "true-by-default", but it's not clear that's actually implemented (it doesn't seem implemented in WebKit at least). Not sure what to make of it. Unless we have some way of testing it I suppose I rather we don't make requirements around this and file a follow-up issue against spellcheck to remove it there as well. Curious to know if @domenic would agree with that or if he sees some kind of model here that is reasonable.

[domenic]

I'd rather keep consistency with spellcheck=""'s exclusion criteria. In general I find the spellcheck="" model reasonable; that's why I suggested copying it.

It's true that spellcheck="" has more possibilities for defaulting, whereas we've decided writingsuggestions="" is always inherit-by-default if there's a parent / true-by-default if there's no parent for the non-excluded elements. That model does seem more simple and I'd support moving spellcheck="" to it, if nobody implements false-by-default.

We do have ways of testing; we can test that element.writingSuggestions === "false" for the elements for which it's excluded from working on.

[annevk]

No we can't test that. I suggested testing that it's false for disabled form controls for instance, but as @dandclark pointed out nothing requires the IDL attribute to be false for that case.

[domenic]

Oh, I see what you mean.

I still think the simplified-spellcheck model (i.e., without true/false by default) is a reasonable one. writingSuggestions and spellcheck IDL attributes control and return according to the content attribute and DOM tree ancestors, even on excluded elements.

Here's a crux case:

<div writingsuggestions="true" spellcheck="true">
  <span>
    <input type="text">
  </span>
</div>

http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=12426

Both models under consideration suggest that inputEl.writingSuggestions === "true" and inputEl.spellcheck === true.

However, the model in this PR suggests that div.writingSuggestions === "true", matching div.spellcheck === true. The model you are proposing, where div.writingSuggestions is influenced by the element exclusions, suggests div.writingSuggestions === "false". This seems to be against the way that reflect-ish IDL attributes usually work, and means there's no JavaScript API beyond getAttribute() for actually probing the DOM state.

Similarly, the model in this PR suggests span.writingSuggestions === "true" (matching span.spellcheck === true). In this case it's probing the DOM state, but doing so by traversing up the tree. That still seems reasonable to me.

[annevk]

I don't think I suggested that the div element in that example should be false? Just that <input disabled> should be.

Anyway, my further point was that if we are not going to take into account <input disabled> in the API, why even say something about it?

[domenic]

I don't think I suggested that the div element in that example should be false? Just that <input disabled> should be.

I thought the suggestion was to reflect all of "User agents must only offer suggestions within an element's scope if the result of running the following algorithm given element returns true:", except I guess not the user-preference portions per https://github.com/whatwg/html/pull/10018#discussion_r1487737039, in the API.

If that's not the suggestion, maybe you could make it more concrete exactly which portions you're proposing to reflect in the API, and why those portions specifically you think are best reflected in the API and not others?

Anyway, my further point was that if we are not going to take into account <input disabled> in the API, why even say something about it?

It seems reasonable for the spec to require that the user not be bothered by writing suggestions in disabled input elements, just like it currently requires that the user not be bothered by spellchecking in such elements. Since the whole section is about browser UI, I agree that it's not 100% clear we're providing value with such requirements; it's not web-observable and probably implementers would figure that out anyway. But I can imagine authors being confused why they get red squiggles or "write for me" popups in <input disabled> on browser X and not browser Y, so adding some basic interop suggestions seems reasonable to me.

We could soften both spellcheck and writing suggestions from "must" to "should", though. That would be congruent with how we treat most other browser UI suggestions.

[dandclark]

We could soften both spellcheck and writing suggestions from "must" to "should", though. That would be congruent with how we treat most other browser UI suggestions.

@annevk, would this address your concern?

[annevk]

Yeah, I think that would work, thanks!

[dandclark]

Yeah, I think that would work, thanks!

Great! I've made that change.

@annevk , @domenic , any other concerns or could we consider landing this PR?

[sanketj]

Thanks everyone for the feedback and reviews.