LGTM2 On Wednesday, October 15, 2025 at 11:19:36 AM UTC-4 Chris Harrelson wrote:
> LGTM1 > > On Wed, Oct 15, 2025 at 8:11 AM 'ASHISH KUMAR' via blink-dev < > [email protected]> wrote: > >> Hi blink-dev reviewers, >> >> I am working to update the underlineStyle and underlineThickness attributes >> of *TextFormat >> <https://developer.mozilla.org/en-US/docs/Web/API/TextFormat>* object in >> EditContext as per the spec >> <https://w3c.github.io/edit-context/#dom-underlinestyle>. Sharing >> the I2S, please let me know if there are any concerns. >> ------------------------------ >> *Contact emails* >> [email protected] >> >> *Specification* >> https://w3c.github.io/edit-context/#textformatupdateevent >> >> *Summary* >> Chromium shipped EditContext >> <https://developer.mozilla.org/en-US/docs/Web/API/EditContext> with a >> bug where the TextFormat >> <https://developer.mozilla.org/en-US/docs/Web/API/TextFormat> object >> supplied by the textformatupdate_event >> <https://developer.mozilla.org/en-US/docs/Web/API/EditContext/textformatupdate_event> >> provides >> incorrect values for the underlineStyle and underlineThickness properties. >> In Chromium the possible values are {“None”, “Solid”, “Dotted”, “Dashed”, >> “Squiggle”} and {“None”, “Thin”, “Thick”}, when per spec: EditContext API >> <https://w3c.github.io/edit-context/#dom-underlinestyle> they should be >> {“none”, “solid”, “dotted”, “dashed”, “wavy”} and {“none”, “thin”, >> “thick”}. This Intent covers switching TextFormat.underlineStyle and >> TextFormat.underlineThickness to use the spec values. >> This change is valuable because it aligns these attributes with existing >> CSS text-decoration-style >> <https://developer.mozilla.org/en-US/docs/Web/CSS/text-decoration-style> and >> the platform convention that enumeration values are lower-cased >> <https://www.w3.org/TR/design-principles/#casing-rules>. Since the >> purpose of the TextFormat properties is to be used in applying these text >> styles to text being composed on behalf of an IME, it will be more >> convenient for developers if the underlineStyle value can be applied >> directly from the event to CSS without need for a remapping. For both >> underlineStyle and underlineThickness, matching the platform lower-case >> convention will reduce the likelihood of developer confusion. >> >> *Blink component* >> Blink>Editing>EditContext >> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EEditing%3EEditContext%22> >> >> *Web Feature ID* >> edit-context <https://webstatus.dev/features/edit-context> >> >> *Search tags* >> editcontext <https://chromestatus.com/features#tags:editcontext>, editing >> <https://chromestatus.com/features#tags:editing>, textformat >> <https://chromestatus.com/features#tags:textformat>, textformatupdate >> <https://chromestatus.com/features#tags:textformatupdate> >> >> *TAG review* >> None – this change fixes a bug where Chromium is out of alignment with >> the EditContext spec, for which the TAG is *already reviewed >> <https://github.com/w3ctag/design-reviews/issues/416>*. >> >> *TAG review status* >> Not applicable >> >> *Risks* >> >> >> *Interoperability and Compatibility* >> This change presents compatibility risk for web applications that >> currently rely on Chrome's non-standardized implementation of >> underlineStyle and underlineThickness values in TextFormatUpdateEvent. >> TextFormatUpdateEvent usage telemetry data from May 2025 onward are: >> 1.* 0.0171%* of page loads register a TextFormatUpdateEvent listener. >> 2. *0.0002%* of page loads fire the event for registered listeners. >> 3. *0.0002%* of page loads include underlineStyle or underlineThickness >> values other than "None" in the fired events. >> Some sites using EditContext such as Google Docs do not use these >> properties, instead electing to apply a consistent underline style to the >> entire active composition. These sites will not be affected. >> EditContext sites that do use these properties (reflected in the above >> use counters) will need to migrate to the new values, feature-detecting the >> change. Sites using the old non-standard values will experience broken >> underlineStyle or underlineThickness in composition until they update to >> the spec-compliant values. We will reach out to known affected customers >> prior to shipping this change to provide migration guidance. >> >> *Gecko*: Positive with concerns for EditContext overall. ( >> https://github.com/mozilla/standards-positions/issues/199) >> >> *WebKit*: Neutral for EditContext overall. ( >> https://github.com/WebKit/standards-positions/issues/243) >> >> *Web developers*: No signals >> >> *Other signals*: >> >> *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?* >> WebView-based applications are expected to have consistent behavior with >> standard web applications. Therefore, the risks for WebView applications >> are similar to web applications. >> >> >> *Debuggability* >> DevTools already supports TextFormats, so no additional debugging support >> is required for this feature. >> >> *Will this feature be supported on all six Blink platforms (Windows, Mac, >> Linux, ChromeOS, Android, and Android WebView)?* >> Yes >> >> *Is this feature fully tested by **web-platform-tests >> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>* >> *?* >> Yes >> >> https://wpt.fyi/results/editing/edit-context/edit-context-textformat.tentative.html >> >> *Flag name on about://flags* >> None >> >> *Finch feature name* >> UseSpecValuesInTextFormatUpdateEventStyles >> >> *Rollout plan* >> Will ship enabled for all users >> >> *Requires code in //chrome?* >> False >> >> *Tracking bug* >> https://issues.chromium.org/issues/354497121 >> >> *Estimated milestones* >> Shipping on desktop >> 143 >> Shipping on Android >> 143 >> Shipping on WebView >> 143 >> Shipping on iOS >> 143 >> >> >> *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/6229300214890496?gate=5198931453673472 >> >> This intent message was generated by Chrome Platform Status >> <https://chromestatus.com/>. >> >> >> ------------------------------ >> Thanks, >> Ashish >> >> -- >> 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 [email protected]. >> To view this discussion visit >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/KUYP153MB1141ABC804E609666E474BE4BAE8A%40KUYP153MB1141.APCP153.PROD.OUTLOOK.COM >> >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/KUYP153MB1141ABC804E609666E474BE4BAE8A%40KUYP153MB1141.APCP153.PROD.OUTLOOK.COM?utm_medium=email&utm_source=footer> >> . >> > -- 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 [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/558f4f81-1be2-4522-91b8-bcef9e787f07n%40chromium.org.
