We just landed a CL <https://chromium-review.googlesource.com/c/chromium/src/+/7138020> that handles the IME issue <https://github.com/w3c/csswg-drafts/issues/13055> raised. Basically, caret-shape is not applicable during IME composition and the caret shape stays as bar. This pretty much reflects the current discussions. A comment <https://github.com/w3c/csswg-drafts/issues/13055#issuecomment-3511768679>has been added to the thread too.
Would it be Okay that we go ahead with the shipping? If the WG has a different solution at a later stage, this could be tweaked in line. On Wednesday, 5 November 2025 at 18:36:50 UTC Ziran Sun wrote: > Thanks very much for the suggestions! We will look into this issue and > follow up the WG discussions if there is any. > > On Wednesday, 5 November 2025 at 16:58:55 UTC Philip Jägenstedt wrote: > >> What I would suggest is to test the current behavior and make any changes >> you think are necessary for a good user experience, to report that on the >> issue and then ship. >> >> FWIW, I tested <textarea style="caret-shape:block"> with a simplified >> Chinese IME on macOS, and I failed to make it misbehave in some obvious >> way. When stepping back to put the caret within the currently uncommitted >> text can insert a space in the string that is the size of a block caret, >> but it does that regardless of the caret shape it seems. >> >> P.S. I also tested caret-shape:🥕 but no hidden easter egg... >> >> On Wed, Nov 5, 2025 at 5:38 PM Stephen Chenney <[email protected]> >> wrote: >> >>> Am I correct in understanding that we can ship and follow up with the >>> IME issue? >>> >>> Regardless we will capture the IME behavior and update the CSS WG issue. >>> With some luck we can get it discussed soon. >>> >>> Cheers, >>> Stephen. >>> >>> On Wed, Nov 5, 2025 at 11:33 AM Philip Jägenstedt <[email protected]> >>> wrote: >>> >>>> LGTM2 >>>> >>>> Stephen, Ziran, how does this interact with IME in Chromium? Can you >>>> document the behavior in >>>> https://github.com/w3c/csswg-drafts/issues/13055 and follow up to >>>> align with the WG resolution when there is one? Updating this thread when >>>> that happens would be much appreciated. >>>> >>>> On Wed, Nov 5, 2025 at 5:27 PM Alex Russell <[email protected]> >>>> wrote: >>>> >>>>> LGTM1, contingent on a resolution to the a11y concern Mike has flagged. >>>>> >>>>> Best, >>>>> >>>>> Alex >>>>> >>>>> On Tuesday, November 4, 2025 at 7:42:58 AM UTC-8 Mike Taylor wrote: >>>>> >>>>>> On 10/29/25 7:34 a.m., Chromestatus wrote: >>>>>> >>>>>> *Contact emails* >>>>>> [email protected], [email protected] >>>>>> >>>>>> *Explainer* >>>>>> https://drafts.csswg.org/css-ui/#caret-shape >>>>>> >>>>>> *Specification* >>>>>> https://drafts.csswg.org/css-ui/#caret-shape >>>>>> >>>>>> *Summary* >>>>>> The shape of the caret in native applications is most commonly a >>>>>> vertical bar, an underscore or a rectangular block. In addition, the >>>>>> shape >>>>>> often varies depending on the input mode, such as insert or replace. The >>>>>> CSS caret-shape property allows sites to choose one of these shapes for >>>>>> the >>>>>> caret inside editable elements, or leave the choice up to the browser. >>>>>> The >>>>>> recognized property values are auto, bar, block and underscore. >>>>>> >>>>>> *Blink component* >>>>>> Blink>CSS >>>>>> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3ECSS%22> >>>>>> >>>>>> *Web Feature ID* >>>>>> caret-shape <https://webstatus.dev/features/caret-shape> >>>>>> >>>>>> *Motivation* >>>>>> To allow authors to specify the desired shape of the text insertion >>>>>> caret. >>>>>> >>>>>> *Initial public proposal* >>>>>> https://drafts.csswg.org/css-ui/#caret-shape >>>>>> >>>>>> *Search tags* >>>>>> caret-shape <http:///features#tags:caret-shape> >>>>>> >>>>>> *TAG review* >>>>>> *No information provided* >>>>>> >>>>>> *TAG review status* >>>>>> Pending >>>>>> >>>>>> *Risks* >>>>>> >>>>>> >>>>>> *Interoperability and Compatibility* >>>>>> *No information provided* >>>>>> >>>>>> *Gecko*: Positive ( >>>>>> https://github.com/mozilla/standards-positions/issues/1211) dholbert >>>>>> commented - "Seems reasonable; I'd suggest a "positive" >>>>>> standards-position. >>>>>> There are a handful of use-cases that use a caret-shape: block sort of >>>>>> rendering that I can find - e.g. gnome-terminal (which lets you choose >>>>>> between Block, I-Beam, and Underline) and the graphical version of >>>>>> emacs. >>>>>> And it seems useful for the web platform to offer the same sort of >>>>>> cosmetic >>>>>> flexibility in matching that caret-style, for web developers who are >>>>>> designing a web-based application inspired by these sorts of native >>>>>> applications. (Masayuki mentions a case in >>>>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1715487#c0 where this >>>>>> sort of feature might make things easier for Korean IME users, too; so >>>>>> there's potentially a usability benefit for some international >>>>>> audiences.)" >>>>>> >>>>>> Note that Masayuki-san also just filed >>>>>> https://github.com/w3c/csswg-drafts/issues/13055, describing cases >>>>>> where this feature might make IMEs harder to use. >>>>>> >>>>>> >>>>>> *WebKit*: No signal ( >>>>>> https://github.com/WebKit/standards-positions/issues/484) >>>>>> >>>>>> *Web developers*: No signals Bloomberg have requested this. Also see >>>>>> above comments by dholbert on possible use cases. >>>>>> >>>>>> *Other signals*: >>>>>> >>>>>> *Activation* >>>>>> No risk. >>>>>> >>>>>> *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? >>>>>> *No information provided* >>>>>> >>>>>> >>>>>> *Debuggability* >>>>>> Support in DevTools. >>>>>> >>>>>> *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 >>>>>> Tests are located at >>>>>> https://github.com/web-platform-tests/wpt/blob/master/css/css-ui/, >>>>>> including Parsing test: caret-shape-parsing.html; caret-shape: block >>>>>> tests: >>>>>> caret-shape-block-001.html caret-shape-block-001-vrl.html >>>>>> caret-shape-block-001-rtl.html caret-shape-block-001-rtl-vlr.html >>>>>> caret-shape-block-001-rtl-vrl.html >>>>>> caret-shape-block-001-rtl-sideways-rl.html >>>>>> caret-shape-block-001-sideways-lr.html >>>>>> caret-shape-block-001-rtl-sideways-lr.html caret-shape-block-002.html >>>>>> caret-shape-block-empty-001.html caret-shape-block-fallback-001.html >>>>>> caret-shape-block-zoom.html; caret-shape: underscore tests: >>>>>> caret-shape-underscore-001.html; caret-shape overflow tests: >>>>>> caret-eol-001.html caret-eol-002.html caret-eol-003.html >>>>>> caret-eol-004.tentative.html. >>>>>> >>>>>> >>>>>> https://wpt.fyi/results/css/css-ui?label=experimental&label=master&aligned, >>>>>> >>>>>> in case others want to see the results at a quick glance. >>>>>> >>>>>> >>>>>> *Flag name on about://flags* >>>>>> Experimental web platform features >>>>>> >>>>>> *Finch feature name* >>>>>> CSSCaretShape >>>>>> >>>>>> *Rollout plan* >>>>>> Will ship enabled for all users >>>>>> >>>>>> *Requires code in //chrome?* >>>>>> False >>>>>> >>>>>> *Tracking bug* >>>>>> https://issues.chromium.org/issues/353713061 >>>>>> >>>>>> *Measurement* >>>>>> Through usual CSS feature counters. >>>>>> >>>>>> *Estimated milestones* >>>>>> >>>>>> No milestones specified >>>>>> >>>>>> >>>>>> *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). >>>>>> *No information provided* >>>>>> >>>>>> *Link to entry on the Chrome Platform Status* >>>>>> >>>>>> https://chromestatus.com/feature/6106160780017664?gate=4913075303743488 >>>>>> >>>>>> *Links to previous Intent discussions* >>>>>> Intent to Prototype: >>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/680b870d.170a0220.15e62e.0520.GAE%40google.com >>>>>> >>>>>> >>>>>> This intent message was generated by Chrome Platform Status >>>>>> <https://chromestatus.com>. >>>>>> >>>>>> -- >>>>>> 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/6901fbb3.050a0220.56be2.0463.GAE%40google.com >>>>>> >>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6901fbb3.050a0220.56be2.0463.GAE%40google.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/88d21f34-5297-4618-9a62-231cb523740bn%40chromium.org >>>>> >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/88d21f34-5297-4618-9a62-231cb523740bn%40chromium.org?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/bd6c084a-d446-4f92-8f6e-8e9052150118n%40chromium.org.
