Intent to Ship: 'writingsuggestions' attribute

[Stephanie Zhang]

Contact emails

sa...@microsoft.com, dan...@microsoft.com, stephan...@microsoft.com

Explainer

https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/WritingSuggestions/explainer.md

Specification

https://html.spec.whatwg.org/multipage/interaction.html#writing-suggestions

Summary

UAs are starting to provide writing suggestions to users as they type on various editable fields across the web. While this is generally useful for users, there are cases when developers may want to turn off UA-provided writing assistance, such as extensions or sites that wish to provide similar functionality on their own. To that end, developers need a solution that would turn on/off UA-provided writing assistance. The new attribute 'writingsuggestions' has values 'true'/'false' that would allow developers to turn on/off browser-provided writing suggestions. The attribute's state for an element can also be inherited from ancestor elements, thereby allowing developers to control this functionality at a per-element or per-document/sub-document scale.

Blink component

Blink>Editing

TAG review

https://github.com/w3ctag/design-reviews/issues/924

TAG review status

Issues addressed

Risks

Interoperability and Compatibility

None

Gecko: No signal (https://github.com/mozilla/standards-positions/issues/855)

WebKit: In development (https://github.com/WebKit/standards-positions/issues/308) WebKit Implementation PR: https://github.com/WebKit/WebKit/pull/24051

Web developers: No signals

Other signals:

Ergonomics

None

Activation

None

Security

None

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

None

Debuggability

None

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

Yes

Attribute is available on all platforms.

Is this feature fully tested by web-platform-tests?

Yes

https://wpt.fyi/results/html/editing/editing-0/writing-suggestions/writingsuggestions.html?label=master&label=experimental&aligned

Flag name on chrome://flags

None

Finch feature name

None

Non-finch justification

No finch trial needed.

Requires code in //chrome?

False

Estimated milestones

Shipping on desktop

124

 

Shipping on Android

124

 

Shipping on WebView

124

 

Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

None

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5153375153029120

Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/rHyRCx-hJhE

This intent message was generated by Chrome Platform Status.

 

[Domenic Denicola]

On Thursday, March 14, 2024 at 2:08:28 AM UTC+9 Stephanie Zhang wrote:

Contact emails

sa...@microsoft.com, daniec@microsoft.com, stephanie.zh...@microsoft.com

Per the flag guidelines, all new features are required to be placed behind a Finch feature flag (i.e. base::Feature flag). Can you ensure this is done and update the Chrome Status entry?

[Stephanie Zhang]

We do have a runtime feature flag 'WritingSuggestions'. We didn't think a Finch Trial was necessary, as the bulk of the changes were just adding the attribute and IDL functions. Since everything is implemented on the blink side, is a Finch feature flag still necessary? If it is, then I'll add that flag :)

[Domenic Denicola]

On Thu, Mar 14, 2024 at 12:54 PM 'Stephanie Zhang' via blink-dev <blin...@chromium.org> wrote:

We do have a runtime feature flag 'WritingSuggestions'. We didn't think a Finch Trial was necessary, as the bulk of the changes were just adding the attribute and IDL functions. Since everything is implemented on the blink side, is a Finch feature flag still necessary? If it is, then I'll add that flag :)

A runtime feature flag automatically generates a Finch flag, unless you turn that off :). So I think this is just a matter of updating the Chrome Status entry.

 

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/8d6a0046-1a9b-44a4-9403-51067ca119fen%40chromium.org.

[Stephanie Zhang]

Thanks for clarifying! Updated the Chrome Status' "Finch Feature Name" field to kWritingSuggestions and removed the "Non-finch justification" field. 

[Domenic Denicola]

Awesome! LGTM1.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/adc944d3-853d-4964-9408-52b4014cc561n%40chromium.org.

[Mike Taylor]

LGTM2

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra_CmAuu_4GVUtG%2BdNxLb8mB4oAXNXZ6PkGmP2jW-F0bxA%40mail.gmail.com.

[Alex Russell]

LGTM3

Awesome! LGTM1.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/adc944d3-853d-4964-9408-52b4014cc561n%40chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Marcos Caceres]

Hi Blink-Dev Friends!

We (WebKit) hit some web compat issues with this feature while testing our implementation is Safari Tech Preview. 

Could you please take a look at:

https://github.com/whatwg/html/issues/10209

And see if there is a way to leave this on by default somehow without affecting websites? 

Looking forward to discussions. 

Marcos 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/adc944d3-853d-4964-9408-52b4014cc561n%40chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra_CmAuu_4GVUtG%2BdNxLb8mB4oAXNXZ6PkGmP2jW-F0bxA%40mail.gmail.com.

[Yoav Weiss (@Shopify)]

Thanks for the heads up, Marcos! :)

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/32ca1052-e460-4245-854b-7e78bd2404b7n%40chromium.org.

[Sanket Joshi (Edge)]

Hi Marcos,

The spec for the writing suggestions attribute doesn't specify how UAs should implement writing suggestions under the hood, it just aims to provide developers with a way to control whether the writing suggestions are shown on their site or not. I don't think this attribute or its on-by-default state carries inherent compat risk. I think any compat issues/quirks would depend on the implementation of writing suggestions, which will vary from browser to browser. I responded in the Github issue too, but we'll likely need to get to the bottom of what is breaking those sites with Safari's implementation of writing suggestions. We can continue discussions on Github.

Thanks,

Sanket

[Marcos Caceres]

On Wednesday, March 20, 2024 at 4:57:56 AM UTC+11 Sanket Joshi (Edge) wrote:

Hi Marcos,

The spec for the writing suggestions attribute doesn't specify how UAs should implement writing suggestions under the hood, it just aims to provide developers with a way to control whether the writing suggestions are shown on their site or not.

Right, but I think what we missed in the spec is describing how this plays with input events, and composition events, which is where this is now causing issues. 

 

I don't think this attribute or its on-by-default state carries inherent compat risk.

It might if the predictive text fires events and participates in the DOM (as it does in WebKit). 

 

I think any compat issues/quirks would depend on the implementation of writing suggestions, which will vary from browser to browser. I responded in the Github issue too, but we'll likely need to get to the bottom of what is breaking those sites with Safari's implementation of writing suggestions. We can continue discussions on Github.

Yes, let's do that. Just think that because we didn't discuss input and composition events as part of standardization, we might have overlooked this aspect. 

Again, it depends on how this is implemented... like floating bubbles on-top of text might not fire events... but combining this with input and composition events seems to have issues. We might have been overly ambitious on the WebKit side making it participate in the composition / event set of events, but not sure. 

[Yoav Weiss (@Shopify)]

On Thu, Mar 21, 2024 at 8:07 AM Marcos Caceres <mar...@marcosc.com> wrote:

On Wednesday, March 20, 2024 at 4:57:56 AM UTC+11 Sanket Joshi (Edge) wrote:

Hi Marcos,

The spec for the writing suggestions attribute doesn't specify how UAs should implement writing suggestions under the hood, it just aims to provide developers with a way to control whether the writing suggestions are shown on their site or not.

Right, but I think what we missed in the spec is describing how this plays with input events, and composition events, which is where this is now causing issues. 

Once the dust settles and we understand why this is causing issues in WebKit, and if/how the Edge implementation has avoided those issues, it'd make sense to revisit the spec here and codify what implementers should be doing to avoid such issues, and ensure interoperability. (either as a note, or as part of the normative spec language, depending on what the investigation would come up with)