+1 to the evidence from OT being persuasive.
LGTM2
On Wednesday, November 8, 2023 at 8:56:24 AM UTC-8 Rick Byers wrote:
It certainly sounds to me that there's additional work to be done
here, but I agree with Daniel that changing event order is not
something we can do lightly. Gregg, could you please file an
issue <https://github.com/w3c/edit-context/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
<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/
<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 <g...@chromium.org>
*Sent:* Tuesday, October 31, 2023 5:19 PM
*To:* Daniel Clark <dan...@microsoft.com>
*Cc:* Gregg Tavares <g...@chromium.org>; blink-dev
<blink-dev@chromium.org>; Alex Keng <shih...@microsoft.com>;
Anupam Snigdha <sni...@microsoft.com>; 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't actually implement across APIs
we'd have that issue.
I wanted to test some things but I don't currently have
access to a windows device and the sample didn't seem to work
on my Mac with the EditContext API enabled.
(*) How is recoversion handled in the canvas example? In a
normal text editing area the user can select a portion of the
text and pick "reconvert" either from menus or via hotkeys
On Wed, Nov 1, 2023 at 8:09 AM Daniel Clark
<dan...@microsoft.com> wrote:
EditContext is not meant to be an interchangeable
replacement for <input type=”text”>, 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 <canvas>). 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 <textarea> 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 <g...@chromium.org
<mailto:g...@chromium.org>>
*Sent:* Monday, October 30, 2023 10:19 PM
*To:* Daniel Clark <dan...@microsoft.com
<mailto:dan...@microsoft.com>>
*Cc:* blink-dev <blink-dev@chromium.org
<mailto:blink-dev@chromium.org>>; Alex Keng
<shih...@microsoft.com <mailto:shih...@microsoft.com>>;
Anupam Snigdha <sni...@microsoft.com
<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 <input type="text"> or <textarea> 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 <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
<https://github.com/w3c/edit-context/blob/gh-pages/explainer.md>
Specification
https://w3c.github.io/edit-context
<https://w3c.github.io/edit-context>
Design docs
https://github.com/w3c/edit-context/blob/gh-pages/dev-design.md
<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
<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/
<https://github.com/w3c/edit-context/>
Origin Trial documentation link
https://github.com/w3c/edit-context/blob/gh-pages/explainer.md
<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
<https://github.com/mozilla/standards-positions/issues/199>)
/WebKit/: No signal
(https://github.com/WebKit/standards-positions/issues/243
<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
<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*
<https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?
Yes.
Tests are available at
https://wpt.fyi/results/editing/edit-context?label=experimental&label=master&aligned
<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
<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-compatible way)./
Open spec issues can be found here:
https://github.com/w3c/edit-context/issues
<https://github.com/w3c/edit-context/issues> We
expect these issues to be resolved in a
forward-compatible way and/or to only affect rare
corner-cases. Many of these discuss potential
additions to the feature that will be considered
based on ongoing developer feedback as EditContext is
adopted more widely.
Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5041440373604352
<https://chromestatus.com/feature/5041440373604352>
Links to previous Intent discussions
Intent to Implement:
https://groups.google.com/u/1/a/chromium.org/g/blink-dev/c/OHqvPx9mFww/m/1za_qdEHDwAJ
<https://groups.google.com/u/1/a/chromium.org/g/blink-dev/c/OHqvPx9mFww/m/1za_qdEHDwAJ>
Intent to Experiment:
https://groups.google.com/u/1/a/chromium.org/g/blink-dev/c/QZQrESwcK3o/m/k3pfYBcRBAAJ
<https://groups.google.com/u/1/a/chromium.org/g/blink-dev/c/QZQrESwcK3o/m/k3pfYBcRBAAJ>
--
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/MW4PR00MB1654118011BA087BA5058967C5A1A%40MW4PR00MB1654.namprd00.prod.outlook.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/MW4PR00MB1654118011BA087BA5058967C5A1A%40MW4PR00MB1654.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
<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/PH7PR00MB1637386167B3A830D5D06D0AC5A7A%40PH7PR00MB1637.namprd00.prod.outlook.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/PH7PR00MB1637386167B3A830D5D06D0AC5A7A%40PH7PR00MB1637.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/6707471d-651b-482d-9047-a5fb0f493680n%40chromium.org
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6707471d-651b-482d-9047-a5fb0f493680n%40chromium.org?utm_medium=email&utm_source=footer>.
