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/CAOMQ%2Bw8QiRn%3DKN5xySZbogoJCwB-1MJ9yu7YuupjW8WSqu96ig%40mail.gmail.com.
