search

w3c / editing

Specs and explainers maintained by the editing task force
http://w3c.github.io/editing/
Other
192 stars 40 forks source link

Interop 2022 and `execCommand` #396

Open whsieh opened 2 years ago

whsieh commented 2 years ago

From https://github.com/web-platform-tests/interop-2022/issues/17, it seems like a large chunk of editing-related WPT reveal inconsistent cross-browser behavior due to different execCommand behaviors.

execCommand is deprecated, but is still used widely on the web. Furthermore, execCommand behavior (and editing in general) behaves differently across different browsers, and even different platforms. How should we proceed with execCommand-related WPT failures?

mbrodesser commented 2 years ago

CC @masayuki-nakano

travisleithead commented 2 years ago

I think this is a potential pandora's box. I wonder how much churn this area of code gets in current implemetations... if not much, then I worry about breaking online editors that may have carefully coded for each browser/OS' ideosyncracies over the years. We could be introducing a lot of churn and pain for the web... when we hope to have better solutions available in the near future (e.g., EditContext).

So, is there actual pain here, or is this a sunk cost for a limited number of online editors?

jgraham commented 2 years ago

There is actual pain here; this is one of the top sources of site compat problems we observe in Gecko. https://bugzilla.mozilla.org/show_bug.cgi?id=1341152 has a lot of linked bugs, but there are more bugs covering observed compat issues. https://bugzilla.mozilla.org/show_bug.cgi?id=1739489 is an example of a recent high-impact bug, for which we're having to ship a site intervention, which is relating to editing events (not strictly execCommand, but related). https://bugzilla.mozilla.org/show_bug.cgi?id=1747008 is another bug where a big site (Wikipedia) was depending on specific browser behaviour and so broke in other implementations. There are more examples of course, but I hope that's enough to convince you that the hypothesis that the editing ecosystem is closely matched to existing browsers, and that therefore isn't causing users problems, isn't really supported by the data.

I also think that just leaving a big area of the web unspecififed in the hope that people eventually move to some new primitives that are themselves not yet specified is not a good way to go about the development of the platform. In the best case it will take many years for new features to displace existing ones, even assuming they fully subsume the use cases. Meanwhile improving implementation alignment on the existing features isn't as exciting but can have immediate benefits because they're already shipping.

FWIW I think (and I stress I haven't checked this with others) a likely/reasonable outcome here might be that the execCommand spec and testsuite are rewritten to match Chromium behaviour in all but the cases where Chromium is actively planning changes. Then other implemenations have a clear specification to aim at and can manage the transition using UA-specific approaches e.g. site interventions.

jgraham commented 2 years ago

Note that I'm currently trying to set up a meeting to discuss this topic; see https://github.com/web-platform-tests/interop-2022-editing/issues/1 if you'd like to be involved in that or in the general editing investigation work as part of Interop 2022.