RE: [blink-dev] Intent to Ship: The Nested Declarations Rule

['Daniel Clark' via blink-dev]

The stated answer to "Will this feature be supported on all six Blink 
platforms" is "No", but I'd expect this to be the same on all platforms - is 
that right?

Could you elaborate a bit on why this might not be doable behind a flag?

-- Dan

From: Anders Hartvoll Ruud 
Sent: Thursday, August 1, 2024 4:14 AM
To: blink-dev 
Subject: [blink-dev] Intent to Ship: The Nested Declarations Rule


Note: See also the previous (failed) 
intent for 
@nest. All CSSWG disagreements around this are now resolved.

Contact emails

andr...@chromium.org

Specification

https://drafts.csswg.org/css-nesting-1/#nested-declarations-rule

Summary


CSS Nesting initially shipped with an interesting quirk that would cause bare 
declarations that come after a nested rule to "shift", for example:


.foo {

  width: 100px;

  height: 100px;

  @media screen {

background-color: red;

  }

  background-color: green;

}


You would think that the background-color of  would be green 
here, but no, that declaration is shifted up to the main (leading) block of 
declarations during parsing:


.foo {

  width: 100px;

  height: 100px;

  background-color: green; /* I'm here now */

  @media screen {

background-color: red;

  }

}


This was at the time done intentionally for a mix of CSSOM and historical 
reasons, and all implementations of CSS Nesting currently agree on this 
behavior. However, it turns out this shifting behavior isn't what authors 
expect (WebKit blog 
post),
 and the CSSWG now consider the decision a mistake. In October 2023, the CSSWG 
resolved
 to not do the shifting behavior anymore, and after a long debate on how to 
handle the implications of this (Issue 
10234), the CSSWG finally 
resolved to introduce the CSSNestedDeclarations rule to solve the problem.

Blink component

Blink>CSS

TAG review

None

TAG review status

Not applicable

Risks


This intent is a breaking change, with two main points of breakage:


  *   Keeping the bare declarations in place can affect the winner of the 
cascade (the example in the introduction). This is covered by 
CSSBareDeclarationShift
 (0.00042%).
  *   Additionally, CSSNestingDeclarations will have different specificity 
behavior for nested group rules, and this can also affect the winner of the 
cascade. This is covered by 
CSSNestedGroupRuleSpecificity
 (0.00046%).

Interoperability and Compatibility


Gecko: No signal (https://github.com/mozilla/standards-positions/issues/1048) - 
"looks acceptable to me". Note that the issue Emilio mentions in his feedback 
has been resolved.


WebKit: No signal on the position itself 
(https://github.com/WebKit/standards-positions/issues/369) - It's however 
slightly ridiculous to request a signal in this case, since this Intent carries 
out WebKit's 
proposal
 exactly.


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?

None

Debuggability

We should be able to reuse the existing inspector feature for nested style 
rules.

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

No

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

Not yet.

Flag name on chrome://flags

None

Finch feature name

None (yet). I'm not yet sure whether or not this change can be done behind a 
flag.

Non-finch justification

None

Requires code in //chrome?

False

Estimated milestones

M129

Anticipated spec changes


None. The last blocking issue 
was closed this week.

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5084403030818816?gate=5133271437148160

This intent message was generated by Chrome Platform 
Status.
--
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+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org

RE: [blink-dev] Web-Facing Change PSA: Update CSS backdrop-filter to use mirror edgeMode

['Daniel Clark' via blink-dev]

Is there a specific set of tests under 
https://wpt.fyi/results/css/filter-effects?label=master&label=experimental&aligned&q=%2Fcss%2Ffilter-effects%2Fbackdrop-filter-
 that highlight this behavior change? I would have expected, for example, some 
set of tests to recently start passing in Chrome due to this change, which 
would already have been passing in Safari and fail in Firefox. But there a 
number of other differences in tests like backdrop-filter-edge-*.html causing 
failures such it's hard to tell what the real status is.



Or are there just too many other browser differences with backdrop-filter to 
make this kind of comparison realistic?



-- Dan

From: Robert Flack 
Sent: Wednesday, July 24, 2024 6:41 AM
To: blink-dev 
Subject: [blink-dev] Web-Facing Change PSA: Update CSS backdrop-filter to use 
mirror edgeMode

Contact emails
fla...@chromium.org, 
michaellud...@google.com


Specification
https://drafts.fxtf.org/filter-effects-2/#backdrop-filter-operation


Summary

The backdrop-filter CSS property applies one or more filters to the "backdrop" 
of an element. The "backdrop" basically means all of the painted content that 
lies behind the element. A common filter is a blur allowing designers to 
construct "frosted glass" dialog boxes, video overlays, translucent navigation 
headers, and more. This was initially implemented the same way as a regular 
blur, but sampling beyond the edges of the element allowed colors from the 
edges to bleed in. The spec was changed to sample pixels outside the backdrop 
edges by duplicating the pixels at the edge. This however, results in extreme 
flickering of content as it enters the backdrop edge. The latest spec change 
mirrors the backdrop when sampling beyond the edge which allows for a smooth 
gradual introduction of new colors at the edges without overweighting on single 
lines of color.



Blink component
Blink>CSS


TAG review
None


TAG review status
Not applicable


Risks



Interoperability and Compatibility

The specific visual result of a blur backdrop-filter is currently quite 
different between Chrome, Firefox and Safari, as such this developers could not 
rely on any interoperable behavior today. This change visually aligns closely 
to Safari's filter - if not identical, so should bring those two in rough 
alignment. We agreed upon this new behavior in the CSSWG resolutions for the 
new edgeMode[1] and using this edgeMode for backdrop-filter[2]. [1] 
https://github.com/w3c/fxtf-drafts/issues/527 [2] 
https://github.com/w3c/fxtf-drafts/issues/374


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

WebKit: No signal (https://github.com/WebKit/standards-positions/issues/372) 
This change is visually very similar to the blur being applied in Safari which 
doesn't have the flickering issues that our current duplicate edgeMode has.

Web developers: No signals There have been many negative signals about the 
current duplicate behavior that this change resolves (all duplicated into the 
main bug): https://issues.chromium.org/issues/40040614 There is positive 
sentiment for Safari's behavior on https://issues.chromium.org/issues/40666159 
and https://issues.chromium.org/issues/40040614 which this change in behavior 
aligns with.

Other signals:


Ergonomics

There are no known ergonomic risks.



Activation

This should be an improvement to the quality of blur backdrop-filters that 
developers are already using and further allow developers to adopt them without 
worrying about the flickering edge cases of the duplicate filter. Developers 
don't need to do anything other than use the backdrop-filter property.



Security

There are no known security risks. This is replacing one sampling algorithm 
with another.



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

As a change to the visual blur, there is no specific debugging support.



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?
Yes

https://wpt.fyi/results/css/filter-effects?label=master&label=experimental&aligned&q=%2Fcss%2Ffilter-effects%2Fbackdrop-filter-



Flag name on chrome://flags
chrome://flags/#backdrop-filter-mirror-edge


Finch feature name
BackdropFilterMirrorEdgeMode


Requires code in //chrome?
False


Tracking bug
https://issues.chromium.org/u/1/issues/40040614


Estimated milestones
Shipping on desktop
129
DevTrial on desktop
127
Shipping on Android
129
DevTrial on Android
127
Shipping on WebView
129



Anticipated spec changes

Open questions about a feature 

RE: [blink-dev] Intent to Ship: Web Authentication API: JSON serialization methods

['Daniel Clark' via blink-dev]

Could you request WebKit’s position for this? 
https://github.com/WebKit/standards-positions/issues/

-- Dan

From: 'Martin Kreichgauer' via blink-dev 
Sent: Friday, July 12, 2024 4:42 PM
To: blink-dev 
Subject: [blink-dev] Intent to Ship: Web Authentication API: JSON serialization 
methods

Contact emails
marti...@google.com


Explainer
https://github.com/w3c/webauthn/wiki/Explainer:-JSON-Serialization-Methods


Specification
https://w3c.github.io/webauthn/#publickeycredential


Summary

The WebAuthn PublicKeyCredential.toJSON(), parseCreationOptionsFromJSON() and 
parseRequestOptionsFromJSON() methods let developers serialize a WebAuthn 
response into a JSON object or deserialize a WebAuthn request object from its 
JSON representation.



Blink component
Blink>WebAuthentication


TAG review
None


TAG review status
Not applicable


Risks



Interoperability and Compatibility

None


Gecko: Shipped/Shipping 
(https://developer.mozilla.org/en-US/docs/Web/API/PublicKeyCredential/toJSON#browser_compatibility)

WebKit: No signal

Web developers: Positive (https://github.com/github/webauthn-json) 
webauthn-json is a widely used polyfill for this API maintained by Github.

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?

None



Debuggability

None



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

This feature is implemented in Blink renderer code and shipping on all 
platforms.



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

https://wpt.fyi/results/webauthn/public-key-credential-creation-options-from-json.https.window.html
 
https://wpt.fyi/results/webauthn/public-key-credential-request-options-from-json.https.window.html
 
https://wpt.fyi/results/webauthn/public-key-credential-to-json.https.window.html



DevTrial instructions
https://docs.google.com/document/d/e/2PACX-1vSl4jywfU4xD3fkWrC-T5hHI79xs90oOq9tVSx4M63WkcI-wuk-nnFlPlDIAttrpTEd5BbXABJnDuxT/pub


Flag name on chrome://flags
enable-experimental-web-platform-features


Finch feature name
WebAuthenticationJSONSerialization


Requires code in //chrome?
False


Tracking bug
https://bugs.chromium.org/p/chromium/issues/detail?id=1401128


Availability expectation
Firefox has shipped an implementation already.


Adoption expectation
There is a widely used polyfill (https://github.com/github/webauthn-json), 
which suggests there is demand from developers for this feature.


Estimated milestones
Shipping on desktop
128
DevTrial on desktop
128

Shipping on Android
128
DevTrial on Android
128

Shipping on WebView
128




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/5141695044255744?gate=6322764007342080


Links to previous Intent discussions
Intent to prototype: 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAB%3DfcEbBz4a%2BEE-KbbRDkEexDON8hCfCC-saD600J7fo9J3jZg%40mail.gmail.com

This intent message was generated by Chrome Platform 
Status.
--
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+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAB%3DfcEYktBpGbDOw9pT40jjE%2B6T4HVCq%2Bzu-P3KMf1PQQuzaew%40mail.gmail.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 blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/MW4PR00MB1455AF88142D18677A0B59D7C5A12%40MW4PR00MB1455.namprd00.prod.outlook.com.

[blink-dev] Intent to Implement and Ship: aria-rowindextext and aria-colindextext

['Daniel Clark' via blink-dev]

Contact emails

dan...@microsoft.com



Explainer

No formal explainer but https://github.com/w3c/aria/issues/667 discusses use 
cases and alternatives.



Specification

https://w3c.github.io/aria/#aria-colindextext, 
https://w3c.github.io/aria/#aria-rowindextext



Summary

The `aria-rowindextext` and `aria-colindextext` properties can be used by 
developers to express semantics about a table or grid to assistive tech. These 
attributes are applied in addition to `aria-rowindex` or `aria-colindex` in 
cases where the numeric indices of rows or columns are not meaningful, for 
example a chessboard or a spreadsheet where the columns are named by letters 
rather than numbers.



These properties are reflected in JavaScript as:

  *   `Element.ariaRowIndexText`
  *   `Element.ariaColIndexText`
  *   `ElementInternals.ariaRowIndexText`
  *   `ElementInternals.ariaColIndexText`



These are part of the Interop2024 Accessibility focus area: 
https://wpt.fyi/results/wai-aria/idlharness.window.html?label=master&label=experimental&aligned&view=interop&q=label%3Ainterop-2024-accessibility



Blink component

Blink>Accessibility



TAG review

These properties were included for WAI-ARIA 1.3 which was reviewed by the TAG 
at https://github.com/w3ctag/design-reviews/issues/927



TAG review status

Resolution: Satisfied



Risks





Interoperability and Compatibility

None





Gecko: Shipped/Shipping



WebKit: No signal (https://bugs.webkit.org/show_bug.cgi?id=257142)



Web developers: No direct signals, but this is part of the Interop2024 
Accessibility focus area: 
https://wpt.fyi/results/?label=master&label=experimental&aligned&view=interop&q=label%3Ainterop-2024-accessibility



Other signals:



Ergonomics

None.







Activation

It isn't possible to polyfill the functionality of delivering the semantics to 
AT. However the properties can be set on browsers that don't support them yet 
without causing errors, so gradual adoption should be straightforward.



The property reflection behavior could be polyfilled if necessary.







Security

We do not anticipate any security impact from this feature.







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

The property values can be observed in chrome://accessibility.



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?

Yes

https://wpt.fyi/results/wai-aria/idlharness.window.html?label=master&label=experimental&aligned&view=interop&q=label%3Ainterop-2024-accessibility

https://wpt.fyi/results/html/dom/aria-attribute-reflection.html?label=master&label=experimental&aligned&view=interop&q=label%3Ainterop-2024-accessibility

https://wpt.fyi/results/custom-elements/ElementInternals-accessibility.html?label=master&label=experimental&aligned&view=interop&q=%2Fcustom-elements%2F







Flag name on chrome://flags

None



Finch feature name

AriaRowColIndexText



Requires code in //chrome?

False



Estimated milestones

Shipping on desktop 128



Anticipated spec changes

None



Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5182419585204224



This intent message was generated by Chrome Platform Status.

-- 
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+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/MW4PR00MB1453C3FD8F1F3CD3E8133243C5C02%40MW4PR00MB1453.namprd00.prod.outlook.com.

RE: [blink-dev] Intent to Ship: Dispatch selectionchange event per element

['Daniel Clark' via blink-dev]

Thanks Shuangshuang for clarifying what’s going on with these two separate but 
related changes, and Olli for the update on 
https://bugzilla.mozilla.org/show_bug.cgi?id=1898343.

Since Gecko already implements the behavior of firing selectionchange on 
input/textarea (confirmed here<https://glow-curvy-cerise.glitch.me/>), sounds 
good to me to go ahead with shipping this change in Chromium (I’m not an API 
owner though).

Separately, for the behavior of not firing duplicate selectionchange, it might 
not hurt to go ahead and request an official Mozilla position on that since it 
sounds like there’s still a bit of uncertainty about landing that change given 
back compat concerns, unless Olli confirms here that the plan is to go ahead 
and ship it.

-- Dan

From: Olli Pettay 
Sent: Friday, May 24, 2024 12:26 AM
To: blink-dev 
Cc: Shuangshuang Zhou ; tk...@chromium.org 
; mike...@chromium.org ; Daniel 
Clark ; Olli Pettay 
Subject: Re: [blink-dev] Intent to Ship: Dispatch selectionchange event per 
element

You don't often get email from opet...@mozilla.com<mailto:opet...@mozilla.com>. 
Learn why this is important<https://aka.ms/LearnAboutSenderIdentification>
FWIW, I'm implementing the change in 
https://bugzilla.mozilla.org/show_bug.cgi?id=1898343
Need to still fix some tests, which do reveal how the spec change indeed isn't 
fully backwards compatible.
Hopefully it doesn't break any real web sites.



-Olli


On Friday, May 24, 2024 at 10:05:47 AM UTC+3 Shuangshuang Zhou wrote:
Hi Dan&Mike, I think we could submit a standard-position issue to Mozilla for 
reducing duplicated events in our second CL(mentioned in my last comment) for 
this feature. Because in the second CL, we might change the current logic of 
dispatching selectionchange event. For this time, we might just do it in 
chromium. WDYT?

Thanks!
On Friday, May 24, 2024 at 9:20:33 AM UTC+8 tk...@chromium.org wrote:
LGTM1.
Firefox and Safari statuses are strong signals, and the compatibility risk 
looks very low.


On Thu, May 23, 2024 at 11:07 AM Shuangshuang Zhou 
mailto:shuangsh...@intel.com>> wrote:
Hi Dan&Mike, for your concern that Firefox is still failing the WPTs at 
https://wpt.fyi/results/selection/onselectionchange-on-distinct-text-controls.html,
 that might be another issue. Let me make more explanation.

Actually, the final goal of w3c modifys the spec of selectionchange event is to 
avoid firing duplicated selectionchange event which are not executed yet on the 
same element(as Rniwa commented in his 
comment<https://github.com/w3c/selection-api/issues/170#issuecomment-1956096554>).
 Then in WebKit/WebCore, Rniwa submitted 2 CLs to achieve this ieda. The first 
CL in WebKit is 276238@main<https://commits.webkit.org/276238@main>, and in 
this CL they just modified the logic to fire selectionchange event on 
input/textarea for the first step. Then the second CL in WebKit is 
276388@main<https://commits.webkit.org/276388@main>, which finally avoided to 
fire duplicated selectionchange events according to the latest spec on firing 
selectionchange 
event<https://w3c.github.io/selection-api/#firing-selectionhange-event>.

So for this feature in Blink here , we also want to take 2 steps like WebKit 
does that in the first CL we change to fire on input/textarea and then sovle 
the duplicated events in the second CL. And those tests are already modified to 
what both CLs are merged. So in the above test of 
onselectionchange-on-distinct-text-controls.html, chrome and firefox should be 
failed because only Safari has landed 2 CLs to avoid duplicated selectionchange 
events. Or in other words, firefox might already dispatch selectionchange event 
on elements but doesn't have the logic to avoid to fire 
scheduled-but-not-executed events.

For WebKit, currently the two CLs are both landed in Safari Technology Preview 
192(link<https://developer.apple.com/documentation/safari-technology-preview-release-notes/stp-release-192>),
 but it might need some time to ship in Safari because Safari is updated within 
OS updates.
For the status in FireFox, I'll double-check and confirm with Tkent(one 
reviewer of my first CL).

Thanks,
Shuangshuang

On Thursday, May 23, 2024 at 9:29:59 AM UTC+8 
mike...@chromium.org<mailto:mike...@chromium.org> wrote:

Yes, agree. Can we please request a position from Mozilla at 
https://github.com/mozilla/standards-positions/issues/new?
On 5/22/24 6:43 PM, 'Daniel Clark' via blink-dev wrote:
Yeah, that’s what I was trying to get at – the Intent implies that Gecko has 
also shipped the breaking change but it seems that might not be the case.

If not, we should send a Request for Position to figure out whether there would 
be cross-browser alignment on shipping this.

-- Dan

From: Olli Pettay mailto:ope...@mozilla.com>>
Sent: Wednesday, May 22, 2024 9:53 AM
To: blink-dev mailto:blin...@chromium.org>>
C

RE: [blink-dev] Intent to Ship: Dispatch selectionchange event per element

['Daniel Clark' via blink-dev]

Yeah, that’s what I was trying to get at – the Intent implies that Gecko has 
also shipped the breaking change but it seems that might not be the case.

If not, we should send a Request for Position to figure out whether there would 
be cross-browser alignment on shipping this.

-- Dan

From: Olli Pettay 
Sent: Wednesday, May 22, 2024 9:53 AM
To: blink-dev 
Cc: Daniel Clark ; Shuangshuang Zhou 

Subject: Re: [blink-dev] Intent to Ship: Dispatch selectionchange event per 
element

You don't often get email from opet...@mozilla.com. 
Learn why this is important
I think it is because of this rather surprising non-backwards compatible recent 
change.
On Wednesday, May 22, 2024 at 7:28:45 PM UTC+3 Daniel Clark wrote:
The Gecko status is marked as Shipped/Shipping and the Interop/Compat section 
mentions Firefox having shipped this, but Firefox is still failing the WPTs at 
https://wpt.fyi/results/selection/onselectionchange-on-distinct-text-controls.html.
Can you help me understand the discrepancy there?

Thanks,
Dan

From: blin...@chromium.org  On Behalf Of Shuangshuang Zhou
Sent: Tuesday, May 21, 2024 10:24 PM
To: blink-dev 
Subject: [blink-dev] Intent to Ship: Dispatch selectionchange event per element

You don't often get email from shuangsh...@intel.com. Learn why this is 
important
Contact emailsshuangsh...@intel.com

ExplainerNone

Specificationhttps://w3c.github.io/selection-api/#selectionchange-event

Summary

Dispatches selectionchange event per element when this element(input/textarea) 
provides a text selection or its selection changes. This is to match the latest 
specification of selectionchange event. This also matches Safari behavior.


Blink 
componentBlink>Editing>Selection

TAG reviewNone

TAG review statusIssues addressed

Risks


Interoperability and Compatibility

Interoperability risk is low because Firefox and Safari have shipped this 
according to the specification. Compatibility risk is low because the 
selectionchange event targeting input/textarea would bubble up, and existing 
codes listening on Document will work well as ever.


Gecko: Shipped/Shipping

WebKit: Shipped/Shipping (https://commits.webkit.org/276238@main)

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?

Low WebView application risks.


Debuggability

None


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?Yes

https://wpt.fyi/results/selection/onselectionchange-on-distinct-text-controls.html


Flag name on chrome://flagsNone

Finch feature nameDispatchSelectionchangeEventPerElement

Requires code in //chrome?False

Tracking bughttps://issues.chromium.org/issues/330766600

Estimated milestones
Shipping on desktop
127

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 
Statushttps://chromestatus.com/feature/5255454895898624?gate=6043023317401600
This intent message was generated by Chrome Platform 
Status.
--
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/de18f3c4-df5a-4423-80ec-e505e0c9fb2bn%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+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/PH8PR00MB1445785C11C8FCA346EAE963C5EB2%40PH8PR00MB1445.namprd00.prod.outlook.com.

RE: [blink-dev] Intent to Ship: Dispatch selectionchange event per element

['Daniel Clark' via blink-dev]

The Gecko status is marked as Shipped/Shipping and the Interop/Compat section 
mentions Firefox having shipped this, but Firefox is still failing the WPTs at 
https://wpt.fyi/results/selection/onselectionchange-on-distinct-text-controls.html.
Can you help me understand the discrepancy there?

Thanks,
Dan

From: blink-dev@chromium.org  On Behalf Of Shuangshuang 
Zhou
Sent: Tuesday, May 21, 2024 10:24 PM
To: blink-dev 
Subject: [blink-dev] Intent to Ship: Dispatch selectionchange event per element

You don't often get email from 
shuangshuang.z...@intel.com. Learn why this 
is important
Contact emailsshuangshuang.z...@intel.com

ExplainerNone

Specificationhttps://w3c.github.io/selection-api/#selectionchange-event

Summary

Dispatches selectionchange event per element when this element(input/textarea) 
provides a text selection or its selection changes. This is to match the latest 
specification of selectionchange event. This also matches Safari behavior.


Blink 
componentBlink>Editing>Selection

TAG reviewNone

TAG review statusIssues addressed

Risks


Interoperability and Compatibility

Interoperability risk is low because Firefox and Safari have shipped this 
according to the specification. Compatibility risk is low because the 
selectionchange event targeting input/textarea would bubble up, and existing 
codes listening on Document will work well as ever.


Gecko: Shipped/Shipping

WebKit: Shipped/Shipping (https://commits.webkit.org/276238@main)

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?

Low WebView application risks.


Debuggability

None


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?Yes

https://wpt.fyi/results/selection/onselectionchange-on-distinct-text-controls.html


Flag name on chrome://flagsNone

Finch feature nameDispatchSelectionchangeEventPerElement

Requires code in //chrome?False

Tracking bughttps://issues.chromium.org/issues/330766600

Estimated milestones
Shipping on desktop
127

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 
Statushttps://chromestatus.com/feature/5255454895898624?gate=6043023317401600

This intent message was generated by Chrome Platform 
Status.
--
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+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/de18f3c4-df5a-4423-80ec-e505e0c9fb2bn%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+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/PH8PR00MB1445096546CE7B423111A3DCC5EB2%40PH8PR00MB1445.namprd00.prod.outlook.com.

RE: [blink-dev] Intent to Ship: Multi-argument alt text in CSS Generated Content

['Daniel Clark' via blink-dev]

> Gecko: No signal (https://bugzilla.mozilla.org/show_bug.cgi?id=1281158)
> It's hard to parse the sentiment in that bug, but it doesn't seem negative at 
> least :) I don't know if it's worth filing a position request

Since I last looked at this bug, Gecko has actually started implementing the 
feature: https://hg.mozilla.org/mozilla-central/rev/df46563babe2. Based on this 
comment<https://hg.mozilla.org/mozilla-central/rev/df46563babe2#l13.37> they’re 
also excluding counter(), so they’ll match the behavior I’m proposing to ship 
here. Looking at https://bugzilla.mozilla.org/show_bug.cgi?id=1896047 the work 
isn’t quite finished yet. So based on these updates I think it’s fair to say 
that the Gecko position is actually “In Development” rather than “No Signal”.
> I believe this is behind the CSSContentMultiArgAltText flag, right?

That’s right.

-- Dan

From: Vladimir Levin 
Sent: Monday, May 13, 2024 11:44 AM
To: Daniel Clark 
Cc: blink-dev@chromium.org
Subject: Re: [blink-dev] Intent to Ship: Multi-argument alt text in CSS 
Generated Content



On Mon, May 13, 2024 at 2:23 PM 'Daniel Clark' via blink-dev 
mailto:blink-dev@chromium.org>> wrote:

Contact emails

dan...@microsoft.com<mailto:dan...@microsoft.com>

Explainer

None

Specification

https://drafts.csswg.org/css-content-3/#valdef-content---string--counter--attr 
and https://drafts.csswg.org/css-content-3/#alt

Summary

The CSS content property allows developers to specify alternative text for 
accessibility with the following syntax:



.has-before-content::before { content: url("cat.jpg") / "A cute cat"; }



This functionality, where the alt text is given by a single string, is already 
supported in Chromium (https://chromestatus.com/feature/4550056227110912). 
However, the spec allows the alt text to be given by an arbitrary number of 
elements, which in addition to strings can be attr() functions or counters.



For example:

.has-before-content::before { content: url("cat.jpg") / "A cute " 
attr(data-animal); }



This Intent tracks the expansion of the Chromium implementation to support an 
arbitrary number of arguments as well as attr() functions in addition to 
strings.



Note that this Intent to Ship does *not* include the addition of counter 
support. This turns out to add significant complexity since counters are 
normally evaluated as part of layout tree computation and the alt text being 
evaluated does not participate in the layout tree. The existing WebKit 
implementation of this feature does not support 
counters<https://github.com/WebKit/WebKit/blob/c1c858cf081e67326c44328c12ab5ddb53a8799b/Source/WebCore/css/parser/CSSPropertyParserHelpers.cpp#L3675>,
 so by shipping what’s proposed here Chromium will align with WebKit.

Blink component

Blink>Accessibility<https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EAccessibility>

TAG review

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



TAG review status

Issues Addressed

Risks

Interoperability and Compatibility

The new syntax will fail to parse in browser where it’s not supported, so until 
browser support is widespread, developers should include a preceding fallback 
line to specify the content:

  .has-before-content::before {

content: url("cat.jpg"); /* Used if the following line doesn't parse */

content: url("cat.jpg") / "A cute " attr(data-animal);

  }



This compat risk is not really new given the feature’s current state of partial 
support.



The lack of counter support in this implementation means there will still be a 
gap between what we’re planning to ship here and the spec. However since 
Chromium already ships a partial implementation, and the updated implementation 
supports more of the spec and puts us into alignment with WebKit, shipping this 
puts things in a strictly better position.

Gecko: No signal (https://bugzilla.mozilla.org/show_bug.cgi?id=1281158)
It's hard to parse the sentiment in that bug, but it doesn't seem negative at 
least :) I don't know if it's worth filing a position request


WebKit: Shipped/Shipping (https://github.com/WebKit/WebKit/pull/22185)

Web developers: There have been several blog posts 
([1]<https://www.sitelint.com/blog/alternative-text-for-css-generated-content>, 
[2]<https://adrianroselli.com/2020/10/alternative-text-for-css-generated-content.html>,
 
[3]<https://www.stefanjudis.com/today-i-learned/css-content-accepts-alternative-text/#edits-part-1-%E2%80%93-define-the-alternative-text-in-html-or-custom-properties>,
 
[4]<https://johnkavanagh.co.uk/articles/alternative-text-in-the-css-content-property/>)
 and a StackOverflow 
answer<https://stackoverflow.com/questions/5943223/put-title-alt-attributes-into-css-after-content-image>
 written about the feature, with positive sentimen

[blink-dev] Intent to Ship: Multi-argument alt text in CSS Generated Content

['Daniel Clark' via blink-dev]

Contact emails

dan...@microsoft.com

Explainer

None

Specification

https://drafts.csswg.org/css-content-3/#valdef-content---string--counter--attr 
and https://drafts.csswg.org/css-content-3/#alt

Summary

The CSS content property allows developers to specify alternative text for 
accessibility with the following syntax:



.has-before-content::before { content: url("cat.jpg") / "A cute cat"; }



This functionality, where the alt text is given by a single string, is already 
supported in Chromium (https://chromestatus.com/feature/4550056227110912). 
However, the spec allows the alt text to be given by an arbitrary number of 
elements, which in addition to strings can be attr() functions or counters.



For example:

.has-before-content::before { content: url("cat.jpg") / "A cute " 
attr(data-animal); }



This Intent tracks the expansion of the Chromium implementation to support an 
arbitrary number of arguments as well as attr() functions in addition to 
strings.



Note that this Intent to Ship does *not* include the addition of counter 
support. This turns out to add significant complexity since counters are 
normally evaluated as part of layout tree computation and the alt text being 
evaluated does not participate in the layout tree. The existing WebKit 
implementation of this feature does not support 
counters,
 so by shipping what's proposed here Chromium will align with WebKit.

Blink component

Blink>Accessibility

TAG review

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



TAG review status

Issues Addressed

Risks

Interoperability and Compatibility

The new syntax will fail to parse in browser where it's not supported, so until 
browser support is widespread, developers should include a preceding fallback 
line to specify the content:

  .has-before-content::before {

content: url("cat.jpg"); /* Used if the following line doesn't parse */

content: url("cat.jpg") / "A cute " attr(data-animal);

  }



This compat risk is not really new given the feature's current state of partial 
support.



The lack of counter support in this implementation means there will still be a 
gap between what we're planning to ship here and the spec. However since 
Chromium already ships a partial implementation, and the updated implementation 
supports more of the spec and puts us into alignment with WebKit, shipping this 
puts things in a strictly better position.

Gecko: No signal (https://bugzilla.mozilla.org/show_bug.cgi?id=1281158)

WebKit: Shipped/Shipping (https://github.com/WebKit/WebKit/pull/22185)

Web developers: There have been several blog posts 
([1], 
[2],
 
[3],
 
[4])
 and a StackOverflow 
answer
 written about the feature, with positive sentiment.

Other signals: This functionality is tested as part of the Interop2024 
Accessibility focus area. Specifically, 
https://wpt.fyi/results/accname/name/comp_name_from_content.html?label=master&label=experimental&aligned&view=interop&q=label%3Ainterop-2024-accessibility
 sub-tests "(button|heading|link) name from fallback content mixing attr() and 
strings with ::before and ::after"

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



Debuggability

The accessible text can be viewed in the accessibility tree via 
chrome://accessibility. DevTools allows this part of the content property to be 
edited in the Style pane.

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://wpt.fyi/results/css/css-content/parsing/content-valid.html

https://wpt.fyi/results/accname/name/comp_name_from_content.html (sub-tests 
"(button|heading|link) name from fallback content mixing attr() and strings 
with ::before and ::after")

Flag name on chrome://flags

None

Finch feature name

None

Non-finch justification

None

Requires code in //chrome?

False

Availability expectation

Already implemented in WebKit. Mozilla bug is 
https://bugzilla.mozilla.org/show_bug.cgi?id=12

RE: [blink-dev] Intent to Ship: Support Video Chapter in MediaMetadata

['Daniel Clark' via blink-dev]

I was curious about WPT coverage for this and found 
https://wpt.fyi/results/mediasession/mediametadata.html

Maybe that could be updated to check for the basics of the new attribute?

-- Dan

From: 'Jiaming Cheng' via blink-dev 
Sent: Tuesday, April 30, 2024 1:50 PM
To: blink-dev@chromium.org
Cc: Alex Newcomer ; Megan Fu ; Tommy 
Steimel ; Andrew Xu 
Subject: [blink-dev] Intent to Ship: Support Video Chapter in MediaMetadata

Contact emails
jiami...@google.com


Explainer
https://github.com/w3c/mediasession/pull/308


Specification
https://www.w3.org/TR/mediasession/#the-chapterinformation-interface


Summary

The corresponding implementation on the blink layer based on the w3c api 
change, which is to add the `ChapterInformation` attribute in the existing 
`MediaMetadata` See the propose: https://github.com/w3c/mediasession/issues/273



Blink component
Blink>Media>Session


TAG review
None


TAG review status
Not applicable


Risks



Interoperability and Compatibility

It's low risk as it's a small addition to an existing API that both Gecko and 
WebKit approve of


Gecko: No signal

WebKit: No signal

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?

None



Debuggability

None



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


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


Flag name on chrome://flags
MediaSessionChapterInformation


Finch feature name
None


Non-finch justification
None


Requires code in //chrome?
False


Sample links

https://googlechrome.github.io/samples/media-session/video.html


Estimated milestones
Shipping on desktop
126






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/6682585059295232?gate=5003115407605760

This intent message was generated by Chrome Platform 
Status.
--
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+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABE8buQTGirUaRRsr9ooud9S%3Dg0OquQy6rGy%2BvnrDtT7T%2BqK%2BQ%40mail.gmail.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 blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/MW4PR00MB1453A46BB0D6695CDE9A9F37C51A2%40MW4PR00MB1453.namprd00.prod.outlook.com.

[blink-dev] Intent to Prototype: Multi-argument alt text in CSS Generated Content

['Daniel Clark' via blink-dev]

Contact emails

dan...@microsoft.com

Explainer

None

Specification

https://www.w3.org/TR/css-content-3/#valdef-content---string--counter

Summary

The CSS content property allows developers to specify alternative text for 
accessibility with the following syntax:



.has-before-content::before { content: url("cat.jpg") / "A cute cat"; }



This functionality is already partially supported in Chromium 
(https://chromestatus.com/feature/4550056227110912) such that the alt text can 
be given by a single string. However, the spec allows the alt text to be given 
by an arbitrary number of arguments, which in addition to strings can be attr() 
functions or counters. For example:



.has-before-content::before { content: url("cat.jpg") / "Cute " 
attr(data-animal) " number " counter(animal-counter); }



This Intent is for the expansion of the Chromium implementation to support the 
full span of arguments permitted by the spec.

Blink component

Blink>Accessibility

Motivation

This will allow developers more flexibility in how they specify alt text for 
generated content, making it easier to build accessible web pages.



Additionally, this functionality is tested as part of the Interop2024 
Accessibility focus area. Specifically, 
https://wpt.fyi/results/accname/name/comp_name_from_content.html?label=master&label=experimental&aligned&view=interop&q=label%3Ainterop-2024-accessibility
 sub-tests "(button|heading|link) name from fallback content mixing attr() and 
strings with ::before and ::after"

Initial public proposal

None

TAG review

None. Omitting TAG review per the guidelines at 
https://www.chromium.org/blink/guidelines/api-owners/process-exceptions/ since 
this is already specified in a CSSWG draft and shipped in WebKit.



TAG review status

Not applicable.



Risks

Interoperability and Compatibility

The new syntax will fail to parse in browser where it's not supported, so until 
browser support is widespread, developers should include a preceding fallback 
line to specify the content:

  .has-before-content::before {

content: url("cat.jpg"); /* Used if the following line doesn't parse */

content: url("cat.jpg") / "Cute " attr(data-animal) " number " 
counter(animal-counter);

  }



This compat risk is not really new given the feature's current state of partial 
support.

Gecko: No signal (https://bugzilla.mozilla.org/show_bug.cgi?id=1281158)

WebKit: Shipped/Shipping (https://github.com/WebKit/WebKit/pull/22185)

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?

None

Debuggability

The accessible text can be viewed in the accessibility tree via 
chrome://accessibility. DevTools will allow this part of the content property 
to be edited in the Style pane.

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

https://wpt.fyi/results/css/css-content/parsing/content-valid.html

https://wpt.fyi/results/accname/name/comp_name_from_content.html (sub-tests 
"(button|heading|link) name from fallback content mixing attr() and strings 
with ::before and ::after")

Flag name on chrome://flags

None

Finch feature name



Non-finch justification

None

Requires code in //chrome?

False

Estimated milestones

No milestones specified



Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5168344402755584

-- 
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+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/MW4PR00MB1455CC35408799CAF44F732CC5162%40MW4PR00MB1455.namprd00.prod.outlook.com.

RE: [blink-dev] Intent to Ship: EditContext API

['Daniel Clark' via blink-dev]

xt/issues> on the spec so the discussion 
can continue there?

Given the positive feedback we have from major real-world deployments in OT and 
the 3+ years of design work that's gone into this API via the editing WG, I 
personally don't think this concern is sufficient to block shipping at this 
stage. Editing is going to continue to be an area to work on improving 
rationality and interop and shipping this API now seems like the right 
pragmatic next step to me. Since fundamentally fixing this issue is going to 
need breaking changes anyway, and EditContext is most likely to be eagerly 
adopted just by a few large applications, I'm reasonably confident that we can 
continue to improve over time as driven by real-world deployment experience. 
LGTM1

Rick

On Wed, Nov 1, 2023 at 2:55 PM 'Daniel Clark' via blink-dev 
mailto:blink-dev@chromium.org>> wrote:
To the extent that firing keydown before compositionstart is a problem for 
apps, that’s an issue that equally affects contenteditable. Changing the order 
may be a good improvement, but it will be a breaking change for the web that 
should be carefully considered and hopefully done in tandem with Firefox and 
Webkit so that browsers can arrive at matching behavior. I think tying 
EditContext to this is not necessary, as EditContext aims to solve a variety of 
problems around receiving text input aside from how keydown specifically is 
handled. Since EditContext does not make any changes around the order of 
keydown relative to other events, shipping EditContext should not add any 
additional complications to changing that event order if the Editing Working 
group decides to go that route.

The API is supported on Mac as well. If the sample you tried didn’t work it may 
be because we failed to update it in response to breaking changes. This sample 
is up-to-date and should serve to show simple text input and composition: 
https://magic-organic-yam.glitch.me/. Note that a lot of basic editing 
functionality isn’t implemented here, and the text formatting for compositions 
is with highlights rather than underlines -- this was built for testing the 
API, not real-world editing.

As part of the Origin Trial, developers at Google Docs and Adobe included Mac 
in their testing and reported several Mac-specific issues that we’ve since 
fixed. If you’d like to try with the Docs implementation, let me know and I can 
ask about getting you opted in to that rollout.

For reconversions, when a page is using EditContext the same UI will still be 
available to the user via the menu or hotkeys. The page keeps the platform 
informed about which text is selected by the user by calling 
EditContext.updateSelection()<https://w3c.github.io/edit-context/#dom-editcontext-updateselection>.
 When the user triggers a reconversion, Blink will send the page another 
TextUpdateEvent<https://w3c.github.io/edit-context/#dom-textupdateevent> 
indicating to it that it should change the text in the specified range to the 
new value.

-- Dan

From: Gregg Tavares mailto:g...@chromium.org>>
Sent: Tuesday, October 31, 2023 5:19 PM
To: Daniel Clark mailto:dan...@microsoft.com>>
Cc: Gregg Tavares mailto:g...@chromium.org>>; blink-dev 
mailto:blink-dev@chromium.org>>; Alex Keng 
mailto:shih...@microsoft.com>>; Anupam Snigdha 
mailto:sni...@microsoft.com>>; 
ko...@chromium.org<mailto:ko...@chromium.org>
Subject: Re: [blink-dev] Intent to Ship: EditContext API

You don't often get email from g...@chromium.org<mailto:g...@chromium.org>. 
Learn why this is important<https://aka.ms/LearnAboutSenderIdentification>
I don't think the keydown issue should be ignored until after shipping this 
API. I think it's essential for this API to actually function.

Consider an app that responds to Control-Shift-J for say "jump to definition".

keydown = key = 'Control'
keydown = key = 'Shift' (CtrlKey = true)
keydown = key = 'K' (CtrlKey = true, Shift = true)  And the app would trigger 
it's jump-to-definition command  But what should have happened is the IME 
switched to Japanese mode (on Mac) and nothing happened in the app.

It seems like this API is supposed to solve these issues but if keydown happens 
first then it seems like it fails at it's actual goal.

The same issue but for different keys exists because of the difference in 
Firefox vs Chrome where in Chrome the app will mistakenly respond to keys it 
shouldn't and in Firefox it won't since Firefox hides those keys as 'Process'.

Other questions:

(*) Are we sure this API matches all platforms? It appears to be only 
implemented on Windows so far. The concern being, without implementing on other 
platforms before shipping, we may run into design issues that require changes 
to the API. I'm not remotely an expert in IME APIs but I know in my own domain, 
GPUs, if we didn

RE: [blink-dev] Intent to Ship: EditContext API

['Daniel Clark' via blink-dev]

le elements that are floated around the page to position 
the IME window.

A site that just wants to receive text input without building out their own 
fully-featured editing experience can and should continue using the existing 
“batteries-included” tools like  or contenteditable.

The keydown event coming before compositionstart seems to be consistent with 
the existing contenteditable behavior in both Chromium and Firefox.  While 
EditContext changes how some editing-related events are fired, some of the 
existing orderings like this were left in place for consistency’s sake when 
there wasn’t a strong reason to change them.

The keydownevent.key interop difference is a good one to note, but I think it 
should be resolved orthogonally to EditContext. Since that behavior difference 
is present for both EditContext and contenteditable, the ideal outcome would be 
to bring this behavior in line across browsers for all editable fields.  It 
looks like there are some stale issues in the EditingWG in that area, e.g. this 
one<https://github.com/w3c/uievents/issues/75> from before Gecko started firing 
keydown/keyup events during composition; maybe this should be taken back up by 
the WG to try to drive further interoperability in the area. If we end up 
making a change there it would apply both to EditContext and to other types of 
editable fields.

-- Dan

From: Gregg Tavares mailto:g...@chromium.org>>
Sent: Monday, October 30, 2023 10:19 PM
To: Daniel Clark mailto:dan...@microsoft.com>>
Cc: blink-dev mailto:blink-dev@chromium.org>>; Alex 
Keng mailto:shih...@microsoft.com>>; Anupam Snigdha 
mailto:sni...@microsoft.com>>; 
ko...@chromium.org<mailto:ko...@chromium.org>
Subject: Re: [blink-dev] Intent to Ship: EditContext API

You don't often get email from g...@chromium.org<mailto:g...@chromium.org>. 
Learn why this is important<https://aka.ms/LearnAboutSenderIdentification>
Not a decider but one that sees the IME on many sites that try to roll their 
own text input.

This sounds like a "if you do all of these 30 things perfectly, then maybe your 
site will work with most IME issues but you won't know unless you get someone 
experienced with IME users to test for you" solution

Vs. some other solution which is "do nothing and it just works".  The current 
"do nothing and it just works" is, use  or  or 
contenteditable.

Is this API just giving developers lots of rope to hang themselves?

Also, how does it align with other browsers? For example the explainer shows a 
sequence of events

Event
EventTarget
key code
event.text
keydown
focused element
'S'
compositionstart
active EditContext
textupdate
active EditContext
'S'
textformatupdate
active EditContext
keyup
focused element
'S'
keydown
focused element
'U'
textupdate
active EditContext
'す'
textformatupdate
active EditContext
keyup
focused element
'U'
keydown
focused element
'Space'
textupdate
active EditContext
'巣'
textformatupdate
active EditContext
compositionend
active EditContext
keyup
focused element
'Space'


That seems non-intuitive to me. I get a keydown first, at which point my app 
reacts when it wasn't supposed to as the key was meant for the IME.

Also, this table doesn't seem to match Firefox for example, pressing 's' when 
in Japanese input mode pops up the IME and in firefox it produces event.key = 
'Process', not event.key = 's' which at least makes more sense since the input 
should be going to the IME, not the page.





On Tue, Oct 31, 2023 at 2:52 AM 'Daniel Clark' via blink-dev 
mailto:blink-dev@chromium.org>> wrote:
Contact emails
dan...@microsoft.com<mailto:dan...@microsoft.com>, 
sni...@microsoft.com<mailto:sni...@microsoft.com>, 
shih...@microsoft.com<mailto:shih...@microsoft.com>
Explainer
https://github.com/w3c/edit-context/blob/gh-pages/explainer.md
Specification
https://w3c.github.io/edit-context
Design docs
https://github.com/w3c/edit-context/blob/gh-pages/dev-design.md
Summary
The EditContext API simplifies the process of integrating a web app with 
advanced text input methods such as IME Compositions and speech recognition, 
and unlocks new capabilities for web-based editors.

Blink component
Blink>Editing<https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EEditing>
Search tags
editing<https://chromestatus.com/features#tags:editing>, 
contenteditable<https://chromestatus.com/features#tags:contenteditable>, 
input<https://chromestatus.com/features#tags:input>, 
rawinput<https://chromestatus.com/features#tags:rawinput>, 
ime<https://chromestatus.com/features#tags:ime>
TAG review
Completed (Resolution: satisifed) at 
https://github.com/w3ctag/design-reviews/issues/416
TAG review status
Issues addressed
Chromium Trial Name
E

RE: [blink-dev] Intent to Ship: EditContext API

['Daniel Clark' via blink-dev]

EditContext is not meant to be an interchangeable replacement for , contenteditable, etc, and most sites that want to receive simple 
text input will want to continue using the existing set of editing features.

The target user of EditContext is one that has already reimplemented a lot of 
the editing stack, such that the browser’s built-in editing functionality is 
more of a hindrance than a help – the typical case here is something like 
Google Docs (where the entire editor view is reimplemented in a ). 
EditContext replaces hacks that sites like these often have to resort to such 
as hidden contenteditable elements that are floated around the page to position 
the IME window.

A site that just wants to receive text input without building out their own 
fully-featured editing experience can and should continue using the existing 
“batteries-included” tools like  or contenteditable.

The keydown event coming before compositionstart seems to be consistent with 
the existing contenteditable behavior in both Chromium and Firefox.  While 
EditContext changes how some editing-related events are fired, some of the 
existing orderings like this were left in place for consistency’s sake when 
there wasn’t a strong reason to change them.

The keydownevent.key interop difference is a good one to note, but I think it 
should be resolved orthogonally to EditContext. Since that behavior difference 
is present for both EditContext and contenteditable, the ideal outcome would be 
to bring this behavior in line across browsers for all editable fields.  It 
looks like there are some stale issues in the EditingWG in that area, e.g. this 
one<https://github.com/w3c/uievents/issues/75> from before Gecko started firing 
keydown/keyup events during composition; maybe this should be taken back up by 
the WG to try to drive further interoperability in the area. If we end up 
making a change there it would apply both to EditContext and to other types of 
editable fields.

-- Dan

From: Gregg Tavares 
Sent: Monday, October 30, 2023 10:19 PM
To: Daniel Clark 
Cc: blink-dev ; Alex Keng ; 
Anupam Snigdha ; ko...@chromium.org
Subject: Re: [blink-dev] Intent to Ship: EditContext API

You don't often get email from g...@chromium.org<mailto:g...@chromium.org>. 
Learn why this is important<https://aka.ms/LearnAboutSenderIdentification>
Not a decider but one that sees the IME on many sites that try to roll their 
own text input.

This sounds like a "if you do all of these 30 things perfectly, then maybe your 
site will work with most IME issues but you won't know unless you get someone 
experienced with IME users to test for you" solution

Vs. some other solution which is "do nothing and it just works".  The current 
"do nothing and it just works" is, use  or  or 
contenteditable.

Is this API just giving developers lots of rope to hang themselves?

Also, how does it align with other browsers? For example the explainer shows a 
sequence of events

Event
EventTarget
key code
event.text
keydown
focused element
'S'
compositionstart
active EditContext
textupdate
active EditContext
'S'
textformatupdate
active EditContext
keyup
focused element
'S'
keydown
focused element
'U'
textupdate
active EditContext
'す'
textformatupdate
active EditContext
keyup
focused element
'U'
keydown
focused element
'Space'
textupdate
active EditContext
'巣'
textformatupdate
active EditContext
compositionend
active EditContext
keyup
focused element
'Space'


That seems non-intuitive to me. I get a keydown first, at which point my app 
reacts when it wasn't supposed to as the key was meant for the IME.

Also, this table doesn't seem to match Firefox for example, pressing 's' when 
in Japanese input mode pops up the IME and in firefox it produces event.key = 
'Process', not event.key = 's' which at least makes more sense since the input 
should be going to the IME, not the page.





On Tue, Oct 31, 2023 at 2:52 AM 'Daniel Clark' via blink-dev 
mailto:blink-dev@chromium.org>> wrote:
Contact emails
dan...@microsoft.com<mailto:dan...@microsoft.com>, 
sni...@microsoft.com<mailto:sni...@microsoft.com>, 
shih...@microsoft.com<mailto:shih...@microsoft.com>
Explainer
https://github.com/w3c/edit-context/blob/gh-pages/explainer.md
Specification
https://w3c.github.io/edit-context
Design docs
https://github.com/w3c/edit-context/blob/gh-pages/dev-design.md
Summary
The EditContext API simplifies the process of integrating a web app with 
advanced text input methods such as IME Compositions and speech recognition, 
and unlocks new capabilities for web-based editors.

Blink component
Blink>Editing<https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EEditing>
Search tags
editing<https://chromestatus.com/features#tags:editing>, 
contented

[blink-dev] Intent to Ship: EditContext API

['Daniel Clark' via blink-dev]

Contact emails
dan...@microsoft.com, 
sni...@microsoft.com, 
shih...@microsoft.com

Explainer
https://github.com/w3c/edit-context/blob/gh-pages/explainer.md

Specification
https://w3c.github.io/edit-context

Design docs
https://github.com/w3c/edit-context/blob/gh-pages/dev-design.md

Summary
The EditContext API simplifies the process of integrating a web app with 
advanced text input methods such as IME Compositions and speech recognition, 
and unlocks new capabilities for web-based editors.

Blink component
Blink>Editing

Search tags
editing, 
contenteditable, 
input, 
rawinput, 
ime

TAG review
Completed (Resolution: satisifed) at 
https://github.com/w3ctag/design-reviews/issues/416

TAG review status
Issues addressed

Chromium Trial Name
EditContext

Link to origin trial feedback summary
https://github.com/w3c/edit-context/

Origin Trial documentation link
https://github.com/w3c/edit-context/blob/gh-pages/explainer.md

In the Origin Trial the Google Docs team used EditContext to receive IME input 
and position the IME window for Docs, replacing the current approach of 
manually positioning a hidden contenteditable element over the document when 
composing text. The new EditContext approach is more performant and supports a 
wider range of IME interactions.

We received similar feedback from Adobe, who are also using EditContext to 
replace a hidden text input element for triggering the IME.

Risks

Interoperability and Compatibility
There are no known interop or compat risks.


Gecko: Under consideration 
(https://github.com/mozilla/standards-positions/issues/199)

WebKit: No signal (https://github.com/WebKit/standards-positions/issues/243)

Web developers: Strongly positive Positive feedback from Word online, Adobe and 
Figma, Google Docs

Other signals:

Ergonomics
None.


Activation
Developers interested in this feature will typically have their own polyfill 
for text input using hidden textarea or contenteditable elements. Feature 
detecting and using new API to avoid side effects of previous approaches is 
intended to be easily adoptable.


Security
No particular security risks. See 
https://github.com/w3c/edit-context/blob/gh-pages/security-privacy.md.


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
Existing DevTools features should be sufficient for debugging EditContext.


Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, 
Chrome OS, Android, and Android WebView)?
Yes. This is a core web platform feature that is not limited to any particular 
underlying platform.


Is this feature fully tested by 
web-platform-tests?
Yes.
Tests are available at 
https://wpt.fyi/results/editing/edit-context?label=experimental&label=master&aligned
 Note that some composition scenarios are not yet testable in WPT due to a 
dependency on content_shell-only test APIs. Work is underway to add 
functionality for mocking IME input in WPTs such that these tests can be moved 
to WPT.


Flag name on chrome://flags
edit-context

Finch feature name
EditContext

Requires code in //chrome?
False

Tracking bug
https://bugs.chromium.org/p/chromium/issues/detail?id=999184

Measurement
The UseCounter WebFeature::kEditContext tracks instantiation of EditContext.

Availability expectation
We expect other browser vendors to be interested in implementing this feature, 
though we cannot comment on specific timelines.

Adoption expectation
Feature will be used by Google Docs upon launch in Chrome.

Adoption plan
We are already working with the Docs team as a partner in the feature's Origin 
Trial, where they have implemented composition using EditContext.

Non-OSS dependencies
Does the feature depend on any code or APIs outside the Chromium open source 
repository and its open-source dependencies to function?
None.

Estimated milestones
Shipping on desktop
121
OriginTrial desktop last
120
OriginTrial desktop first
116

OriginTrial Android last
120
OriginTrial Android first
116

OriginTrial webView last
120
OriginTrial webView first
116


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

RE: [blink-dev] Intent to Experiment: EditContext API

['Daniel Clark' via blink-dev]

Hi Nicola,
The textformatupdate event does not get fired in response to browser spell 
checking. It's only used for decorations applied by IMEs to give hints to users 
during composition, e.g. thin/thick underlines for "phrase mode" in Japanese 
IME.
Spell checking for an EditContext depends on how the author builds the view of 
their Editor.
If the author builds with "normal" DOM elements -- , , etc -- the 
platform will run the spell-checker on these like any other editable elements, 
drawing the underlines and allowing the user to choose corrections. EditContext 
will not see any of this, and will only be able to tell at the point that the 
user has chosen a suggestion, e.g. by listening for beforeinput with 
event.inputType === "insertReplacementText". So spell-checking will work much 
like a normal contenteditable div today.
If the author uses , the platform's native spellcheck will have no way 
to integrate with the EditContext. By using , the author is taking on 
the responsibility for building out their editor from scratch, including 
spell-checking if needed by their application.
-- Dan

From: Nicola Tommasi 
Sent: Tuesday, June 27, 2023 1:03 AM
To: blink-dev 
Cc: Daniel Clark ; Yoav Weiss ; 
Mike Taylor ; blin...@chromium.org 
; Joshua Bell ; chri...@google.com 
; Anupam Snigdha ; Alex Keng 
; mt...@google.com ; Alex Russell 
; Arthur Sonzogni 
Subject: Re: [blink-dev] Intent to Experiment: EditContext API

Hi, from a privacy perspective we have some concerns regarding the spellchecker 
section: we enforced in the past the concept that websites should not learn 
about the user dictionaries [1] and it seems like the spellcheking API proposal 
could leak those via the textformatupdate event. Was this taken into 
consideration?Do we have any way to prevent this?

[1] https://drafts.csswg.org/css-pseudo-4/#highlight-security

Thanks,
Nicola
On Thursday, June 15, 2023 at 11:31:59 PM UTC 
dan...@microsoft.com<mailto:dan...@microsoft.com> wrote:
Thanks Alex!

It looks like 
crbug.com/1263817<https://bugs.chromium.org/p/chromium/issues/detail?id=1263817>
 is a good tracking bug for https://github.com/w3c/uievents/issues/202 (which 
is already linked from there). Since EditContext differs in how these events 
will fire I think this issue can be resolved separately, but I’ve tagged some 
folks in on that issue to try to drive some progress.

I’ll investigate what can be done to get the tests moved to WPT.

From: Alex Russell mailto:slightly...@chromium.org>>
Sent: Wednesday, June 14, 2023 8:32 AM
To: blink-dev mailto:blink-dev@chromium.org>>
Cc: Yoav Weiss mailto:yoavwe...@chromium.org>>; Mike 
Taylor mailto:miketa...@chromium.org>>; 
blin...@chromium.org<mailto:blin...@chromium.org> 
mailto:blink-dev@chromium.org>>; Joshua Bell 
mailto:jsb...@chromium.org>>; 
chri...@google.com<mailto:chri...@google.com> 
mailto:chris...@google.com>>; Anupam Snigdha 
mailto:sni...@microsoft.com>>; Alex Keng 
mailto:shih...@microsoft.com>>; Daniel Clark 
mailto:dan...@microsoft.com>>; 
mt...@google.com<mailto:mt...@google.com> 
mailto:m...@google.com>>
Subject: Re: [blink-dev] Intent to Experiment: EditContext API

LGTM to experiment assuming WPT caveats are addressed.

On editing event order, perhaps we can track this separately. Is there a crbug 
for it?
On Tuesday, June 13, 2023 at 9:02:34 PM UTC-7 Yoav Weiss wrote:
On Wed, Jun 14, 2023 at 12:03 AM 'Daniel Clark' via blink-dev 
mailto:blink-dev@chromium.org>> wrote:
> Although in the template this is phrased as a yes/no question, can you say 
> more about the WPT coverage and limitations?

We currently do not have tests in web-platform-tests.
There are tests outside the external/wpt folder:
third_party/blink/web_tests/editing/input/edit-context.html<https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/editing/input/edit-context.html>
third_party/blink/web_tests/editing/input/edit-context-dom-mutation.html<https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/editing/input/edit-context-dom-mutation.html>

I’m going to migrate as much of the contents of these as I can to WPT. This 
won’t be possible for a lot of the subtests since they rely on primitives like 
eventSender and textInputController, which aren’t available in WPT.
There is also test coverage that still needs to be written for scenarios 
involving nested editable elements, and I plan to add these as WPTs.

Would it be possible to add WebDriver extensions to enable these tests to move 
over to WPT?

+Mathias Bynens<mailto:m...@google.com> - FYI


There’s been some work 
done<https://chromium-review.googlesource.com/c/chromium/src/+/3009937> around 
adding support for IME testing but my understanding is that more work is needed 
in order to use this in WPTs.

From: Danie

RE: [blink-dev] Intent to Experiment: EditContext API

['Daniel Clark' via blink-dev]

Thanks Alex!

It looks like 
crbug.com/1263817<https://bugs.chromium.org/p/chromium/issues/detail?id=1263817>
 is a good tracking bug for https://github.com/w3c/uievents/issues/202 (which 
is already linked from there). Since EditContext differs in how these events 
will fire I think this issue can be resolved separately, but I’ve tagged some 
folks in on that issue to try to drive some progress.

I’ll investigate what can be done to get the tests moved to WPT.

From: Alex Russell 
Sent: Wednesday, June 14, 2023 8:32 AM
To: blink-dev 
Cc: Yoav Weiss ; Mike Taylor ; 
blin...@chromium.org ; Joshua Bell 
; chri...@google.com ; Anupam Snigdha 
; Alex Keng ; Daniel Clark 
; mt...@google.com 
Subject: Re: [blink-dev] Intent to Experiment: EditContext API

LGTM to experiment assuming WPT caveats are addressed.

On editing event order, perhaps we can track this separately. Is there a crbug 
for it?
On Tuesday, June 13, 2023 at 9:02:34 PM UTC-7 Yoav Weiss wrote:
On Wed, Jun 14, 2023 at 12:03 AM 'Daniel Clark' via blink-dev 
mailto:blink-dev@chromium.org>> wrote:
> Although in the template this is phrased as a yes/no question, can you say 
> more about the WPT coverage and limitations?

We currently do not have tests in web-platform-tests.
There are tests outside the external/wpt folder:
third_party/blink/web_tests/editing/input/edit-context.html<https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/editing/input/edit-context.html>
third_party/blink/web_tests/editing/input/edit-context-dom-mutation.html<https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/editing/input/edit-context-dom-mutation.html>

I’m going to migrate as much of the contents of these as I can to WPT. This 
won’t be possible for a lot of the subtests since they rely on primitives like 
eventSender and textInputController, which aren’t available in WPT.
There is also test coverage that still needs to be written for scenarios 
involving nested editable elements, and I plan to add these as WPTs.

Would it be possible to add WebDriver extensions to enable these tests to move 
over to WPT?

+Mathias Bynens<mailto:m...@google.com> - FYI


There’s been some work 
done<https://chromium-review.googlesource.com/c/chromium/src/+/3009937> around 
adding support for IME testing but my understanding is that more work is needed 
in order to use this in WPTs.

From: Daniel Clark
Sent: Tuesday, June 13, 2023 10:42 AM
To: Mike Taylor mailto:miketa...@chromium.org>>; 
blink-dev@chromium.org<mailto:blink-dev@chromium.org>
Cc: Chris Harrelson mailto:chris...@google.com>>; Anupam 
Snigdha mailto:sni...@microsoft.com>>; Alex Keng 
mailto:shih...@microsoft.com>>
Subject: RE: [blink-dev] Intent to Experiment: EditContext API

Tentatively M116 - M120 for the trial.

From: Mike Taylor mailto:miketa...@chromium.org>>
Sent: Tuesday, June 13, 2023 9:24 AM
To: Daniel Clark mailto:dan...@microsoft.com>>; 
blink-dev@chromium.org<mailto:blink-dev@chromium.org>
Cc: Chris Harrelson mailto:chris...@google.com>>; Anupam 
Snigdha mailto:sni...@microsoft.com>>; Alex Keng 
mailto:shih...@microsoft.com>>
Subject: Re: [blink-dev] Intent to Experiment: EditContext API


Do you all have a timeline in mind for experimentation?
On 6/12/23 7:00 PM, 'Daniel Clark' via blink-dev wrote:
Contact emails
sni...@microsoft.com<mailto:sni...@microsoft.com>, 
shih...@microsoft.com<mailto:shih...@microsoft.com>, 
bemat...@microsoft.com<mailto:bemat...@microsoft.com>, 
dan...@microsoft.com<mailto:dan...@microsoft.com>

Explainer
https://github.com/w3c/edit-context/blob/gh-pages/explainer.md

Specification
https://w3c.github.io/edit-context

Design docs

https://github.com/w3c/edit-context/blob/gh-pages/dev-design.md

Summary

The EditContext API simplifies the process of integrating a web app with 
advanced text input methods such as VK shape-writing, Handwriting panels, 
speech recognition, IME Compositions etc., improves accessibility and 
performance, and unlocks new capabilities for web-based editors.


Blink component
Blink>Editing<https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EEditing>

Search tags
editing<https://chromestatus.com/features#tags:editing>, 
contenteditable<https://chromestatus.com/features#tags:contenteditable>, 
input<https://chromestatus.com/features#tags:input>, 
rawinput<https://chromestatus.com/features#tags:rawinput>, 
ime<https://chromestatus.com/features#tags:ime>

TAG review
https://github.com/w3ctag/design-reviews/issues/416

TAG review status
Pending

Risks


Interoperability and Compatibility

There are no known interop or compat risks.


Gecko: No signal

WebKit: No signal
It'd be good to file for positions (even if that doesn't block an OT)


Web developers: Strongly positive Positive fe

RE: [blink-dev] Intent to Experiment: EditContext API

['Daniel Clark' via blink-dev]

> Although in the template this is phrased as a yes/no question, can you say 
> more about the WPT coverage and limitations?

We currently do not have tests in web-platform-tests.
There are tests outside the external/wpt folder:
third_party/blink/web_tests/editing/input/edit-context.html<https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/editing/input/edit-context.html>
third_party/blink/web_tests/editing/input/edit-context-dom-mutation.html<https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/editing/input/edit-context-dom-mutation.html>

I'm going to migrate as much of the contents of these as I can to WPT. This 
won't be possible for a lot of the subtests since they rely on primitives like 
eventSender and textInputController, which aren't available in WPT.
There is also test coverage that still needs to be written for scenarios 
involving nested editable elements, and I plan to add these as WPTs.

There's been some work 
done<https://chromium-review.googlesource.com/c/chromium/src/+/3009937> around 
adding support for IME testing but my understanding is that more work is needed 
in order to use this in WPTs.

From: Daniel Clark
Sent: Tuesday, June 13, 2023 10:42 AM
To: Mike Taylor ; blink-dev@chromium.org
Cc: Chris Harrelson ; Anupam Snigdha 
; Alex Keng 
Subject: RE: [blink-dev] Intent to Experiment: EditContext API

Tentatively M116 - M120 for the trial.

From: Mike Taylor mailto:miketa...@chromium.org>>
Sent: Tuesday, June 13, 2023 9:24 AM
To: Daniel Clark mailto:dan...@microsoft.com>>; 
blink-dev@chromium.org<mailto:blink-dev@chromium.org>
Cc: Chris Harrelson mailto:chris...@google.com>>; Anupam 
Snigdha mailto:sni...@microsoft.com>>; Alex Keng 
mailto:shih...@microsoft.com>>
Subject: Re: [blink-dev] Intent to Experiment: EditContext API


Do you all have a timeline in mind for experimentation?
On 6/12/23 7:00 PM, 'Daniel Clark' via blink-dev wrote:
Contact emails
sni...@microsoft.com<mailto:sni...@microsoft.com>, 
shih...@microsoft.com<mailto:shih...@microsoft.com>, 
bemat...@microsoft.com<mailto:bemat...@microsoft.com>, 
dan...@microsoft.com<mailto:dan...@microsoft.com>


Explainer
https://github.com/w3c/edit-context/blob/gh-pages/explainer.md


Specification
https://w3c.github.io/edit-context


Design docs

https://github.com/w3c/edit-context/blob/gh-pages/dev-design.md


Summary

The EditContext API simplifies the process of integrating a web app with 
advanced text input methods such as VK shape-writing, Handwriting panels, 
speech recognition, IME Compositions etc., improves accessibility and 
performance, and unlocks new capabilities for web-based editors.



Blink component
Blink>Editing<https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EEditing>


Search tags
editing<https://chromestatus.com/features#tags:editing>, 
contenteditable<https://chromestatus.com/features#tags:contenteditable>, 
input<https://chromestatus.com/features#tags:input>, 
rawinput<https://chromestatus.com/features#tags:rawinput>, 
ime<https://chromestatus.com/features#tags:ime>


TAG review
https://github.com/w3ctag/design-reviews/issues/416


TAG review status
Pending


Risks



Interoperability and Compatibility

There are no known interop or compat risks.


Gecko: No signal

WebKit: No signal

Web developers: Strongly positive Positive feedback from Word online, Adobe and 
Figma, Google Docs

Other signals:


Activation

Developers interested in this feature will typically have their own polyfill 
for text input using hidden textarea or contenteditable elements. Feature 
detecting and using new API to avoid side effects of previous approaches is 
intended to be easily adoptable.



WebView application risks

None

Goals for experimentation
We are looking for feedback on the developer ergonomics of using the API and 
for confirmation that it meets the needs of production web apps for various 
input modes. This is a complex API, and different developers are expected to 
use it in different ways. For example, some partners plan to construct the view 
of their editable region in the subtree of the EditContext-associated element, 
while other partners plan to keep the EditContext-associated element off-screen 
while using the EditContext APIs to set the bounds of the editable region.

We want to ensure that our design enables all these scenarios and is robust 
given the wide field of IMEs utilized by different users, which may have subtly 
different behaviors and event timings.


Ongoing technical constraints

None



Debuggability
Existing DevTools functionality should suffice to debug EditContext.
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, 
Chrome OS, Android, and Android WebView)?
Yes


Is this feature fully tested by 
web-platform-tests<http

RE: [blink-dev] Intent to Experiment: EditContext API

['Daniel Clark' via blink-dev]

Tentatively M116 - M120 for the trial.

From: Mike Taylor 
Sent: Tuesday, June 13, 2023 9:24 AM
To: Daniel Clark ; blink-dev@chromium.org
Cc: Chris Harrelson ; Anupam Snigdha 
; Alex Keng 
Subject: Re: [blink-dev] Intent to Experiment: EditContext API


Do you all have a timeline in mind for experimentation?
On 6/12/23 7:00 PM, 'Daniel Clark' via blink-dev wrote:
Contact emails
sni...@microsoft.com<mailto:sni...@microsoft.com>, 
shih...@microsoft.com<mailto:shih...@microsoft.com>, 
bemat...@microsoft.com<mailto:bemat...@microsoft.com>, 
dan...@microsoft.com<mailto:dan...@microsoft.com>



Explainer
https://github.com/w3c/edit-context/blob/gh-pages/explainer.md



Specification
https://w3c.github.io/edit-context



Design docs

https://github.com/w3c/edit-context/blob/gh-pages/dev-design.md



Summary

The EditContext API simplifies the process of integrating a web app with 
advanced text input methods such as VK shape-writing, Handwriting panels, 
speech recognition, IME Compositions etc., improves accessibility and 
performance, and unlocks new capabilities for web-based editors.




Blink component
Blink>Editing<https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EEditing>



Search tags
editing<https://chromestatus.com/features#tags:editing>, 
contenteditable<https://chromestatus.com/features#tags:contenteditable>, 
input<https://chromestatus.com/features#tags:input>, 
rawinput<https://chromestatus.com/features#tags:rawinput>, 
ime<https://chromestatus.com/features#tags:ime>



TAG review
https://github.com/w3ctag/design-reviews/issues/416



TAG review status
Pending



Risks




Interoperability and Compatibility

There are no known interop or compat risks.


Gecko: No signal

WebKit: No signal

Web developers: Strongly positive Positive feedback from Word online, Adobe and 
Figma, Google Docs

Other signals:



Activation

Developers interested in this feature will typically have their own polyfill 
for text input using hidden textarea or contenteditable elements. Feature 
detecting and using new API to avoid side effects of previous approaches is 
intended to be easily adoptable.




WebView application risks

None

Goals for experimentation
We are looking for feedback on the developer ergonomics of using the API and 
for confirmation that it meets the needs of production web apps for various 
input modes. This is a complex API, and different developers are expected to 
use it in different ways. For example, some partners plan to construct the view 
of their editable region in the subtree of the EditContext-associated element, 
while other partners plan to keep the EditContext-associated element off-screen 
while using the EditContext APIs to set the bounds of the editable region.

We want to ensure that our design enables all these scenarios and is robust 
given the wide field of IMEs utilized by different users, which may have subtly 
different behaviors and event timings.



Ongoing technical constraints

None




Debuggability
Existing DevTools functionality should suffice to debug EditContext.
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, 
Chrome OS, 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>?
No



Flag name
--enable-blink-features=EditContext



Requires code in //chrome?
False



Tracking bug
https://bugs.chromium.org/p/chromium/issues/detail?id=999184



Estimated milestones

No milestones specified




Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5041440373604352



Links to previous Intent discussions
I2I: 
https://groups.google.com/u/1/a/chromium.org/g/blink-dev/c/OHqvPx9mFww/m/1za_qdEHDwAJ


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 
blink-dev+unsubscr...@chromium.org<mailto:blink-dev+unsubscr...@chromium.org>.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/SN6PR00MB0448C960D827BFAFE2FD1F2CC554A%40SN6PR00MB0448.namprd00.prod.outlook.com<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/SN6PR00MB0448C960D827BFAFE2FD1F2CC554A%40SN6PR00MB0448.namprd00.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 blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/DM5PR00MB0439CBA75AB03CF21A2AA19CC555A%40DM5PR00MB0439.namprd00.prod.outlook.com.

[blink-dev] Intent to Experiment: EditContext API

['Daniel Clark' via blink-dev]

Contact emails
sni...@microsoft.com, 
shih...@microsoft.com, 
bemat...@microsoft.com, 
dan...@microsoft.com


Explainer
https://github.com/w3c/edit-context/blob/gh-pages/explainer.md


Specification
https://w3c.github.io/edit-context


Design docs

https://github.com/w3c/edit-context/blob/gh-pages/dev-design.md


Summary

The EditContext API simplifies the process of integrating a web app with 
advanced text input methods such as VK shape-writing, Handwriting panels, 
speech recognition, IME Compositions etc., improves accessibility and 
performance, and unlocks new capabilities for web-based editors.



Blink component
Blink>Editing


Search tags
editing, 
contenteditable, 
input, 
rawinput, 
ime


TAG review
https://github.com/w3ctag/design-reviews/issues/416


TAG review status
Pending


Risks



Interoperability and Compatibility

There are no known interop or compat risks.


Gecko: No signal

WebKit: No signal

Web developers: Strongly positive Positive feedback from Word online, Adobe and 
Figma, Google Docs

Other signals:


Activation

Developers interested in this feature will typically have their own polyfill 
for text input using hidden textarea or contenteditable elements. Feature 
detecting and using new API to avoid side effects of previous approaches is 
intended to be easily adoptable.



WebView application risks

None



Goals for experimentation
We are looking for feedback on the developer ergonomics of using the API and 
for confirmation that it meets the needs of production web apps for various 
input modes. This is a complex API, and different developers are expected to 
use it in different ways. For example, some partners plan to construct the view 
of their editable region in the subtree of the EditContext-associated element, 
while other partners plan to keep the EditContext-associated element off-screen 
while using the EditContext APIs to set the bounds of the editable region.

We want to ensure that our design enables all these scenarios and is robust 
given the wide field of IMEs utilized by different users, which may have subtly 
different behaviors and event timings.


Ongoing technical constraints

None



Debuggability
Existing DevTools functionality should suffice to debug EditContext.


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


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


Flag name
--enable-blink-features=EditContext


Requires code in //chrome?
False


Tracking bug
https://bugs.chromium.org/p/chromium/issues/detail?id=999184


Estimated milestones

No milestones specified



Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5041440373604352


Links to previous Intent discussions
I2I: 
https://groups.google.com/u/1/a/chromium.org/g/blink-dev/c/OHqvPx9mFww/m/1za_qdEHDwAJ

This intent message was generated by Chrome Platform 
Status.

-- 
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+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/SN6PR00MB0448C960D827BFAFE2FD1F2CC554A%40SN6PR00MB0448.namprd00.prod.outlook.com.

RE: [blink-dev] Intent to Ship: Custom Highlight API

['Daniel Clark' via blink-dev]

Thanks for following through with that fix and reland! Highlight API has 
shipped: https://chromium-review.googlesource.com/c/chromium/src/+/3718885

From: Delan Azabani 
Sent: Friday, July 15, 2022 1:16 AM
To: blink-dev 
Cc: Delan Azabani ; jme...@google.com 
; Daniel Bratell ; 
yoav...@chromium.org ; blink-dev 
; Manuel Rego ; Sanket Joshi (EDGE) 
; Fernando Fiori ; Bo Cupp 
; Luis Juan Sanchez Padilla ; 
rby...@chromium.org ; flo...@rivoal.net 
; Daniel Clark 
Subject: Re: [blink-dev] Intent to Ship: Custom Highlight API

You don't often get email from de...@azabani.com. 
Learn why this is important
On Friday, 24 June 2022 at 3:42:07 pm UTC+8 Delan Azabani wrote:
I think all of the blocking spec issues are now resolved or at consensus, so 
the only thing left is the Chromium OS performance regression in bug 
1335762.
 It's hard to give a time estimate on that until we figure out the root cause 
though.

We've fixed the regression and rebumped HighlightOverlayPainting to stable, so 
we should be good to go!

-- 
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+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/MW2PR00MB0441ECC40E388EE533E923F8C58B9%40MW2PR00MB0441.namprd00.prod.outlook.com.

RE: [blink-dev] Intent to Ship: Custom Highlight API

['Daniel Clark' via blink-dev]

These are both good points, thanks for bringing them up. I won't plan to block 
shipping for these but I'll follow up for both.

I filed https://bugs.chromium.org/p/chromium/issues/detail?id=1344685 to track 
the addition of the console warning.
I filed https://github.com/w3c/csswg-drafts/issues/7499 to track clarification 
of the printing behavior.

Thanks,
Dan

-Original Message-
From: Manuel Rego Casasnovas  
Sent: Thursday, July 14, 2022 4:31 AM
To: Daniel Clark ; blink-dev 
Cc: Sanket Joshi (EDGE) ; Fernando Fiori 
; Bo Cupp ; Luis Juan Sanchez 
Padilla ; Delan Azabani ; 
Emilio Cobos Álvarez ; Rick Byers ; 
Florian Rivoal 
Subject: Re: [blink-dev] Intent to Ship: Custom Highlight API

One comment about this feature and legacy layout.

It seems ::highlight customization is only supported in LayoutNG for most 
properties (only background-color works in legacy).

I'm wondering if we should add some kind of console warning message, like for 
Container Queries [*], so if people see some differences in some cases they can 
know the reason why.


Another thing that I noticed is that highlight pseudos are not being printed, I 
guess that was on purpose for things like ::selection or ::target-text, but 
should we allow printing ::highlight? Should we open a spec issue about that so 
it's properly defined (I didn't find anything on the specs regarding printing)?

I don't mean this is a blocker for shipping, but if this is not properly 
defined, maybe it's time to clarify things regarding printing.

Cheers,
  Rego

[*] 
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fchromium-review.googlesource.com%2Fc%2Fchromium%2Fsrc%2F%2B%2F3706582&data=05%7C01%7Cdaniec%40microsoft.com%7Ce900e8a35b984e0378ea08da658c4bd3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637933950515742925%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=jQM8QtQRPqgZls%2F9HsfJrCfZgyS27G6dNHZeFIDr2sc%3D&reserved=0

On 08/06/2022 19:42, 'Daniel Clark' via blink-dev wrote:
> 
> Contact emails
> 
> dan...@microsoft.com <mailto:dan...@microsoft.com>, 
> sa...@microsoft.com <mailto:sa...@microsoft.com>, ffi...@microsoft.com 
> <mailto:ffi...@microsoft.com>, lusan...@microsoft.com 
> <mailto:lusan...@microsoft.com>, pc...@microsoft.com 
> <mailto:pc...@microsoft.com>,
> 
> 
> Explainer
> 
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> ub.com%2FMicrosoftEdge%2FMSEdgeExplainers%2Fblob%2Fmain%2Fhighlight%2F
> explainer.md&data=05%7C01%7Cdaniec%40microsoft.com%7Ce900e8a35b984
> e0378ea08da658c4bd3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63793
> 3950515742925%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2lu
> MzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=gltxN5Ppd
> jpK2hmy9YOvzmv4JCoBz5fEy6VKu8r5wvI%3D&reserved=0
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit
> hub.com%2FMicrosoftEdge%2FMSEdgeExplainers%2Fblob%2Fmain%2Fhighlight%2
> Fexplainer.md&data=05%7C01%7Cdaniec%40microsoft.com%7Ce900e8a35b98
> 4e0378ea08da658c4bd3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6379
> 33950515742925%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2l
> uMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=gltxN5Pp
> djpK2hmy9YOvzmv4JCoBz5fEy6VKu8r5wvI%3D&reserved=0>
> 
> 
> Specification
> 
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdraf
> ts.csswg.org%2Fcss-highlight-api-1%2F&data=05%7C01%7Cdaniec%40micr
> osoft.com%7Ce900e8a35b984e0378ea08da658c4bd3%7C72f988bf86f141af91ab2d7
> cd011db47%7C1%7C0%7C637933950515742925%7CUnknown%7CTWFpbGZsb3d8eyJWIjo
> iMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%
> 7C%7C&sdata=cx9ESC489CebPDKkllktvpHmsUei2QQBKAwG3m16%2Fw4%3D&r
> eserved=0 
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdra
> fts.csswg.org%2Fcss-highlight-api-1%2F&data=05%7C01%7Cdaniec%40mic
> rosoft.com%7Ce900e8a35b984e0378ea08da658c4bd3%7C72f988bf86f141af91ab2d
> 7cd011db47%7C1%7C0%7C637933950515742925%7CUnknown%7CTWFpbGZsb3d8eyJWIj
> oiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C
> %7C%7C&sdata=cx9ESC489CebPDKkllktvpHmsUei2QQBKAwG3m16%2Fw4%3D&
> reserved=0>
> 
> 
> Design docs
> 
> 
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs
> .google.com%2Fdocument%2Fd%2F1vaWiPLA9opz0AObbObuRj3P5zqzoM2ldy0pHkZkJ
> yxo&data=05%7C01%7Cdaniec%40microsoft.com%7Ce900e8a35b984e0378ea08
> da658c4bd3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63793395051574
> 2925%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBT
> iI6Ik1haWwiLC

RE: [blink-dev] Intent to Ship: Custom Highlight API

['Daniel Clark' via blink-dev]

Re: [blink-dev] Intent to Ship: Custom Highlight API


On Thursday, June 9, 2022 at 6:55:06 AM UTC+2 Manuel Rego wrote:
I'm biased here as I've been working on this feature myself, so I cannot
give an official LGTM.

Thanks for all the work since the previous intent thread, I believe this
is now in a way better status to ship.

I'd be fine giving a LGTM with the following caveats:
* As mentioned at the end of the email, HighlightOverlayPainting flag
gets enabled before shipping this (that flag fixes lots of bugs
regarding paining of CSS highlight pseudos).
* The following CSSWG issue gets resolved:
https://github.com/w3c/csswg-drafts/issues/6774<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%2Fcsswg-drafts%2Fissues%2F6774&data=05%7C01%7Cdaniec%40microsoft.com%7C3ab8d4cef9a44046d14808da547349d8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637915151411080842%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=PoHUWPF%2B%2F%2Fm1HU7NYPYZxsJMWJt9HdPxHGbkdL31yC4%3D&reserved=0>
It looks like there's an agreement already but it'd be nice to confirm
it, as this might change behavior if a different decision is made.

Other than that I've just some minor comments inline.

On 08/06/2022 19:42, 'Daniel Clark' via blink-dev wrote:
> Risks
>
>
> Interoperability and Compatibility
>
> Low risk: This feature received positive support from Safari and Firefox
> at TPAC 2019. Safari is implementing it, Firefox has not yet made any
> clear indication on implementation.

What's the feature detection/activation story here? Can developers use the 
feature while it's partially supported? What would be the implications of that?


>
>
>
> /Gecko/: No clear signal
> (https://github.com/mozilla/standards-positions/issues/482<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmozilla%2Fstandards-positions%2Fissues%2F482&data=05%7C01%7Cdaniec%40microsoft.com%7C3ab8d4cef9a44046d14808da547349d8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637915151411080842%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2FuU8uekd%2FwJwyVcTdjR3%2FsYYQr%2FZ4FsZan6wEbdJZgM%3D&reserved=0>
> <https://github.com/mozilla/standards-positions/issues/482<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmozilla%2Fstandards-positions%2Fissues%2F482&data=05%7C01%7Cdaniec%40microsoft.com%7C3ab8d4cef9a44046d14808da547349d8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637915151411080842%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2FuU8uekd%2FwJwyVcTdjR3%2FsYYQr%2FZ4FsZan6wEbdJZgM%3D&reserved=0>>)

We could send a ping notifying that Chromium is planning to ship.

> /WebKit/: Positive. WebKit implemented the feature behind an
> experimental flag in 99:
> https://developer.apple.com/safari/technology-preview/release-notes/#:~:text=Added%20support%20for%20rendering%20highlights%20specified%20in%20CSS%20Highlight%20API<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper.apple.com%2Fsafari%2Ftechnology-preview%2Frelease-notes%2F%23%3A~%3Atext%3DAdded%2520support%2520for%2520rendering%2520highlights%2520specified%2520in%2520CSS%2520Highlight%2520API&data=05%7C01%7Cdaniec%40microsoft.com%7C3ab8d4cef9a44046d14808da547349d8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637915151411080842%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=gUFrWdDxg%2Bv3nZApKFHs3XZYStpprO8Gk8%2B4DDoKhSc%3D&reserved=0>
> <https://developer.apple.com/safari/technology-preview/release-notes/#:~:text=Added%20support%20for%20rendering%20highlights%20specified%20in%20CSS%20Highlight%20API<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper.apple.com%2Fsafari%2Ftechnology-preview%2Frelease-notes%2F%23%3A~%3Atext%3DAdded%2520support%2520for%2520rendering%2520highlights%2520specified%2520in%2520CSS%2520Highlight%2520API&data=05%7C01%7Cdaniec%40microsoft.com%7C3ab8d4cef9a44046d14808da547349d8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637915151411080842%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=gUFrWdDxg%2Bv3nZApKFHs3XZYStpprO8Gk8%2B4DDoKhSc%3D&reserved=0>>.

I agree that it's positive WebKit has a WIP implementation. But just to
clarify the status Safari has an old version of this spec implemented,
and the implementation is not complete and not up to date regarding the
spec (e.g. 
https://bugs.webkit.org/show_bug.cgi?id=229797<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.webkit.org%2Fshow_bug.cgi%3Fid%3D229797&

RE: [blink-dev] Intent to Ship: Custom Highlight API

['Daniel Clark' via blink-dev]

> What's the feature detection/activation story here? Can developers use the 
> feature while it's partially supported? What would be the implications of 
> that?

Feature detection can be done by checking for the presence of CSS.highlights:

function supportsHighlightAPI() {
  return !!CSS.highlights;
}

For use cases where the highlights are key to the user experience (e.g. when 
used for an app's custom find-on-page implementation), developers should fall 
back to a polyfill for unsupported browsers. For use cases where highlights are 
only added for stylistic purposes, they could be omitted altogether when there 
isn't support.

A polyfill could be built for the feature that works by wrapping "highlighted" 
content in styled spans. This could get tricky to implement for cases involving 
many nested highlights (which is one thing that the API makes much easier), but 
it would work fine for most scenarios.

> We could send a ping notifying that Chromium is planning to ship.

I pinged the mozilla/standards-positions thread about this last week, still 
waiting to hear back 
https://github.com/mozilla/standards-positions/issues/482#issuecomment-1152601522.
 @Emilio<mailto:emi...@mozilla.com>, is there anything you'd be able to share 
about this?

> Can you ask for an explicit signal to see what their plans are on that front? 
> Is there an interop risk from their incomplete implementation?

I sent a 
mail<https://lists.webkit.org/pipermail/webkit-dev/2022-June/032303.html> to 
webkit-dev, awaiting response. I just took another look at their 
implementation, and they've done some work to bring it closer to the current 
state of the spec since last I checked. The remaining major difference I see is 
just the lack of support for live Ranges. I expect that they will close this 
gap prior to shipping the feature. If they don't then the difference could also 
be feature-detected by polyfills:

function supportsLiveRangeHighlights() {
  try {
new Highlight(new Range());
return true;
  } catch(ex) {
return false;
  };
}

-- Dan

From: Yoav Weiss 
Sent: Wednesday, June 15, 2022 1:32 AM
To: blink-dev 
Cc: Manuel Rego ; Sanket Joshi (EDGE) ; 
Fernando Fiori ; Bo Cupp ; Luis Juan 
Sanchez Padilla ; Delan Azabani 
; Emilio Cobos Alvarez ; Rick Byers 
; flo...@rivoal.net ; Daniel Clark 

Subject: Re: [blink-dev] Intent to Ship: Custom Highlight API


On Thursday, June 9, 2022 at 6:55:06 AM UTC+2 Manuel Rego wrote:
I'm biased here as I've been working on this feature myself, so I cannot
give an official LGTM.

Thanks for all the work since the previous intent thread, I believe this
is now in a way better status to ship.

I'd be fine giving a LGTM with the following caveats:
* As mentioned at the end of the email, HighlightOverlayPainting flag
gets enabled before shipping this (that flag fixes lots of bugs
regarding paining of CSS highlight pseudos).
* The following CSSWG issue gets resolved:
https://github.com/w3c/csswg-drafts/issues/6774<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%2Fcsswg-drafts%2Fissues%2F6774&data=05%7C01%7Cdaniec%40microsoft.com%7C7feca281f397491f36cc08da4ea98e04%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637908787402809854%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=FVgZmds%2BpoWNSGjSR1DFoh3G1dwFwes5vZD65iEDdtA%3D&reserved=0>
It looks like there's an agreement already but it'd be nice to confirm
it, as this might change behavior if a different decision is made.

Other than that I've just some minor comments inline.

On 08/06/2022 19:42, 'Daniel Clark' via blink-dev wrote:
> Risks
>
>
> Interoperability and Compatibility
>
> Low risk: This feature received positive support from Safari and Firefox
> at TPAC 2019. Safari is implementing it, Firefox has not yet made any
> clear indication on implementation.

What's the feature detection/activation story here? Can developers use the 
feature while it's partially supported? What would be the implications of that?


>
>
>
> /Gecko/: No clear signal
> (https://github.com/mozilla/standards-positions/issues/482<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmozilla%2Fstandards-positions%2Fissues%2F482&data=05%7C01%7Cdaniec%40microsoft.com%7C7feca281f397491f36cc08da4ea98e04%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637908787402809854%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=zEMcL5OP4APO1YKe2SGFBKlASHSGQOy1bi%2FreiGIBY4%3D&reserved=0>
> <https://github.com/mozilla/standards-positions/issues/482<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmozilla%2Fstandards-positions%2Fissues%2F482&data=05%7C0

[blink-dev] Intent to Ship: Custom Highlight API

['Daniel Clark' via blink-dev]

Contact emails
dan...@microsoft.com, 
sa...@microsoft.com, 
ffi...@microsoft.com, 
lusan...@microsoft.com, 
pc...@microsoft.com,

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


Specification
https://drafts.csswg.org/css-highlight-api-1/


Design docs

https://docs.google.com/document/d/1vaWiPLA9opz0AObbObuRj3P5zqzoM2ldy0pHkZkJyxo


Summary

The custom highlight API provides a way for web developers to style the text of 
arbitrary ranges. This is useful in a variety of scenarios, including editing 
frameworks that wish to implement their own selection, find-on-page over 
virtualized documents, multiple selections to represent online collaboration, 
or spellchecking frameworks.



Blink component
Blink>Editing


Search tags
Custom Highlight 
API, Highlight 
API


TAG review
https://github.com/w3ctag/design-reviews/issues/584


TAG review status
Issues addressed


Risks


Interoperability and Compatibility

Low risk: This feature received positive support from Safari and Firefox at 
TPAC 2019. Safari is implementing it, Firefox has not yet made any clear 
indication on implementation.


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

WebKit: Positive. WebKit implemented the feature behind an experimental flag in 
99: 
https://developer.apple.com/safari/technology-preview/release-notes/#:~:text=Added%20support%20for%20rendering%20highlights%20specified%20in%20CSS%20Highlight%20API.

Web developers: Strongly positive 
(https://github.com/w3c/csswg-drafts/issues/4307). Multiple use cases have been 
pointed out in this issue. CKEditor has also shown support from the first 
highlight API explainer.

Other signals:


Ergonomics

Highlight API will be the first use case for constructible StaticRanges, which 
the API permits as an alternative to Iive Ranges because they do not incur cost 
during DOM mutations.



Activation

No. Web developers should be able to use the feature as-is. It is also easy to 
feature detect (checking for the existence of CSS.highlights).



WebView application risks
None.


Debuggability

DevTools shows ::highlight pseudo elements in the style pane. This includes 
inherited pseudos per the highlight inheritance 
model used by custom 
highlights.



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


Is this feature fully tested by 
web-platform-tests?
Yes
https://github.com/web-platform-tests/wpt/tree/master/css/css-highlight-api

Flag name
HighlightAPI


Requires code in //chrome?
False


Tracking bug
https://crbug.com/1164461


Estimated milestones

No milestones specified


Anticipated spec changes

Future work will likely add support for setting pointer event listeners on 
highlights so that highlights can react to user input. For some early thoughts 
on this see 
https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/highlight/events-explainer.md.
 That work will not be a compat risk; it would be only additive.



Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5436441440026624


Links to previous Intent discussions
Intent to prototype: 
https://groups.google.com/a/chromium.org/g/blink-dev/c/Ix2u8NHG5Po/m/jjMjWIHXAQAJ
Earlier Intent to ship: 
https://groups.google.com/a/chromium.org/g/blink-dev/c/Q21B  
Qb-zV0w/m/2ik0_aKyCAAJ

Additional Comments:
We sent an earlier Intent to 
Ship
 for this feature last year where we received feedback about several spec and 
implementation issues that needed to be resolved prior to shipping. We have now 
addressed these issues. Things that have changed since the initial I2S include:
- Custom highlights have been switched to use highlight pseudo 
inheritance, 
resolving longstanding disagreements between how highlight pseudos work in 
Chromium versus what is said in the spec.
- Many highlight painting bugs have been fixed by Igalia's work in this space. 
Note: Some of these fixes came from the HighlightOverlayPainting work that was 
landed in https://chromium-review.googlesource.com/c/chromium/src/+/3640642. 
That change was reverted due to a perf issue, so we'll wait for it to reland 
prior to landing the shipping CL for Custom Highlight API.
- 

RE: [blink-dev] Intent to Ship: Custom Highlight API

['Daniel Clark' via blink-dev]

Thanks Rick!

Yes, I definitely think that the browser's built-in find-on-page could be 
redefined using this. In Chromium at least they are already implemented using 
some of the same structures (DocumentMarker for keeping track of highlight 
positions). I think further down the line it could be worthwhile to look at 
fully transitioning things like find-on-page to Highlight API.

-- Dan

From: Rick Byers 
Sent: Friday, August 13, 2021 8:58 AM
To: Daniel Clark 
Cc: emi...@mozilla.com; blink-dev@chromium.org; Fernando Fiori 
; Bo Cupp ; Sanket Joshi (EDGE) 

Subject: Re: [blink-dev] Intent to Ship: Custom Highlight API

LGTM1 - looks great to me!

"Explaining" and exposing magic rendering properties of the platform like 
highlighting is super valuable, thank you! Out of curiosity, if this gets broad 
support do you think there's an opportunity to redefine things like 
find-in-page highlights to be built (conceptually if not physically) on top of 
this primitive?

Rick

On Thu, Aug 12, 2021 at 6:36 PM 'Daniel Clark' via blink-dev 
mailto:blink-dev@chromium.org>> wrote:
Oh, you're right, I hadn't realized they still have it off by default.
So my mail should have said that WebKit has implemented it but not shipped it.

-Original Message-
From: Emilio Cobos Álvarez mailto:emi...@mozilla.com>>
Sent: Thursday, August 12, 2021 3:13 PM
To: Daniel Clark mailto:dan...@microsoft.com>>; 
blink-dev@chromium.org<mailto:blink-dev@chromium.org>
Cc: Fernando Fiori mailto:ffi...@microsoft.com>>; Bo Cupp 
mailto:pc...@microsoft.com>>; Sanket Joshi (EDGE) 
mailto:sa...@microsoft.com>>
Subject: Re: [blink-dev] Intent to Ship: Custom Highlight API

Is Safari actually shipping it? What I see is that they implement it as a 
(default off) experimental feature, which I don't think qualifies as "shipping" 
by any means.

  -- Emilio

On 8/12/21 23:23, 'Daniel Clark' via blink-dev wrote:
>
> Contact emails
>
> sa...@microsoft.com<mailto:sa...@microsoft.com> 
> <mailto:sa...@microsoft.com<mailto:sa...@microsoft.com>>, 
> ffi...@microsoft.com<mailto:ffi...@microsoft.com>
> <mailto:ffi...@microsoft.com<mailto:ffi...@microsoft.com>>, 
> pc...@microsoft.com<mailto:pc...@microsoft.com>
> <mailto:pc...@microsoft.com<mailto:pc...@microsoft.com>>, 
> dan...@microsoft.com<mailto:dan...@microsoft.com>
> <mailto:dan...@microsoft.com<mailto:dan...@microsoft.com>>
>
>
> Explainer
>
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> ub.com<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fub.com%2F&data=04%7C01%7Cdaniec%40microsoft.com%7Ca71f75ba2d2e48fc292f08d95e731cc4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637644670804496490%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=GQj24GD%2BFjutpQYag0Q4S5%2B4ndi8dr%2BZD0p54tJW0aY%3D&reserved=0>%2FMicrosoftEdge%2FMSEdgeExplainers%2Fblob%2Fmain%2Fhighlight%2F
> explainer.md&data=04%7C01%7Cdaniec%40microsoft.com<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=04%7C01%7Cdaniec%40microsoft.com%7Ca71f75ba2d2e48fc292f08d95e731cc4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637644670804506485%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=huqr%2FszxQBvjZssaIlgK7%2Bjaig%2BkqYhHdqVKnHqWnU4%3D&reserved=0>%7C18a8e4ed1ccc4
> 482d4dc08d95dde6345%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63764
> 4032020524159%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2lu
> MzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=%2FZClTeCRozA8x8hx
> 1c0AodwctVLfVg5Fi7QhZz7RadI%3D&reserved=0
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit
> hub.com<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhub.com%2F&data=04%7C01%7Cdaniec%40microsoft.com%7Ca71f75ba2d2e48fc292f08d95e731cc4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637644670804506485%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=rcr%2FDBezOImPeo9xN7ZFWWcCiB3ghdJPAv7ULdEsUe0%3D&reserved=0>%2FMicrosoftEdge%2FMSEdgeExplainers%2Fblob%2Fmain%2Fhighlight%2
> Fexplainer.md&data=04%7C01%7Cdaniec%40microsoft.com<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=04%7C01%7Cdaniec%40microsoft.com%7Ca71f75ba2d2e48fc292f08d95e731cc4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637644670804516478%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=%2BpYfYENfdVVYqd4PbkkaxL63we5%2FxOIznBvm8XcysIs%3D&reserved=0>%7C18a8e4ed1ccc
> 4482d4dc08d95

RE: [blink-dev] Intent to Ship: Custom Highlight API

['Daniel Clark' via blink-dev]

2Fcss-pseudo-4%2F%23highlight-pseudos&data=04%7C01%7Cdaniec%40microsoft.com%7C6113ef857bf7463196a308d95ea1bf59%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637644871086330959%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=BVOmsUayTL3qxgka8VSBDABT%2BmxAfv%2BUHpORvSCK5Kg%3D&reserved=0>,
 and Chrome's current behavior is actually far from spec compliant here. 
Luckily, this is in the process of being fixed, but shipping custom highights 
before landing those fixes risks causing a compat problem: if people start to 
use custom highlight with the current/broken cascading and painting model, and 
then we fix it, that's liable to cause plenty of annoyances. As long as fixing 
those is considered a dependency for this intent to ship, then that's great, 
but shipping the API first and fixing the behavior later is maybe not so great. 
See at least 
https://bugs.chromium.org/p/chromium/issues/detail?id=1147859<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.chromium.org%2Fp%2Fchromium%2Fissues%2Fdetail%3Fid%3D1147859&data=04%7C01%7Cdaniec%40microsoft.com%7C6113ef857bf7463196a308d95ea1bf59%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637644871086340952%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=lQWB%2FvbcX0GUimfT4CwFe%2BvBFLiVcKzme78BLySAie0%3D&reserved=0>

-Florian


On Aug 12, 2021, at 23:23, 'Daniel Clark' via blink-dev 
mailto:blink-dev@chromium.org>> wrote:

Contact emails

sa...@microsoft.com<mailto:sa...@microsoft.com>, 
ffi...@microsoft.com<mailto:ffi...@microsoft.com>, 
pc...@microsoft.com<mailto:pc...@microsoft.com>, 
dan...@microsoft.com<mailto:dan...@microsoft.com>

Explainer

https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/highlight/explainer.md<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoftEdge%2FMSEdgeExplainers%2Fblob%2Fmain%2Fhighlight%2Fexplainer.md&data=04%7C01%7Cdaniec%40microsoft.com%7C6113ef857bf7463196a308d95ea1bf59%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637644871086340952%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=BpzVAw9s7%2Fc7r%2BZo1zrrqbw34TzgL4VkT8KovB3qdlk%3D&reserved=0>

Specification
https://drafts.csswg.org/css-highlight-api-1/<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdrafts.csswg.org%2Fcss-highlight-api-1%2F&data=04%7C01%7Cdaniec%40microsoft.com%7C6113ef857bf7463196a308d95ea1bf59%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637644871086350965%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=dWllFXbxdi%2FtANEnHxFEPNymFkyUpzuWcOuFCDOnw9A%3D&reserved=0>

Summary
The custom highlight API provides a way for web developers to style the text of 
arbitrary ranges. This is useful in a variety of scenarios, including editing 
frameworks that wish to implement their own selection, find-on-page over 
virtualized documents, multiple selections to represent online collaboration, 
or spellchecking frameworks.



Blink component

Blink>Editing<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.chromium.org%2Fp%2Fchromium%2Fissues%2Flist%3Fq%3Dcomponent%3ABlink%253EEditing&data=04%7C01%7Cdaniec%40microsoft.com%7C6113ef857bf7463196a308d95ea1bf59%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637644871086350965%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=9Z6rW9escgxsGZSKu5yHFNLeGoRf1t2aXIG1jgGLo5w%3D&reserved=0>

Search tags

Custom Highlight 
API<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fchromestatus.com%2Ffeatures%23tags%3ACustom%2520Highlight%2520API&data=04%7C01%7Cdaniec%40microsoft.com%7C6113ef857bf7463196a308d95ea1bf59%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637644871086360963%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=qOgkLXG16y36NEK8hH11WvX4bT56so%2FGSZ1bOA%2Bhimo%3D&reserved=0>,
 Highlight 
API<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fchromestatus.com%2Ffeatures%23tags%3AHighlight%2520API&data=04%7C01%7Cdaniec%40microsoft.com%7C6113ef857bf7463196a308d95ea1bf59%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637644871086360963%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=UkupBjpTl4YUA0Hd4LEgKCkBdoh4%2F%2BpB2AXx0BH2AKo%3D&reserved=0>

TAG review

https://github.com/w3ctag/design-reviews/issues/584<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3ctag%2Fdesign-reviews%2Fissues%2F584&data=04%7C01%7Cdaniec%40microsoft.com%7C6113ef857bf7463196a308d95ea1bf59%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6376448710