Re: [w3c/editing] Contenteditable re-creating deleted children when it shouldn't (Issue #468)

From meeting minutes 2025-01-09:

> 08:02 <whsieh> issue https://github.com/w3c/editing/issues/468
08:03 <whsieh> johanneswilm: several proposed solutions in GH issue
08:06 <whsieh> johanneswilm: what if we removed empty bold tag if the selection was moved?
08:06 <whsieh> johanneswilm: but this is weird because changing selection could change the DOM
08:07 <whsieh> zcorpan: also DOM changes could affect layout which is not ideal when changing selection
08:07 <whsieh> zcorpan: and this only makes sense for bold, not all typing styles (font size, font family, etc.)
08:07 <whsieh> zcorpan: any other alternatives?
08:08 <whsieh> zcorpan: FWIW there's already document.queryCommandState
08:08 <whsieh> zcorpan: (though this only works for built-in editing commands like bold, not font size)
08:09 <zcorpan> https://w3c.github.io/editing/docs/execCommand/#querycommandstate()
08:09 <whsieh> johanneswilm: this is execCommand-adjacent, which we're trying to move away from
08:10 <whsieh> johanneswilm: we might even want to communicate other state like caret blinking, font info, etc.
08:10 <whsieh> johanneswilm: yet another approach was to have multiple input events (extra formatbold)
08:11 <whsieh> johanneswilm: ......or maybe a separate input type like `insertStyledText`
08:11 <whsieh> johanneswilm: going back to `queryCommandState`, I don't think it'll work with EditContext
08:11 <whsieh> dandclark: ones that are not rich text dependent will work
08:12 <whsieh> dandclark: automatic insertion of bold/other formatting does not apply to EditContext
08:13 <whsieh> johanneswilm: maybe we should invent something that makes sense for EditContext for consistency
08:13 <whsieh> zcorpan: new idea — can we use mutation observer to detect?
08:13 <whsieh> zcorpan: (rather, can the web dev use mutationobserver)
08:13 <whsieh> johanneswilm: idea of input events is that developer shouldn't need to do this
08:14 <whsieh> johanneswilm: but maybe solution is "we don't fix this since it's superseded by EditContext and developers make it mostly work already in cE using queryCommandState and/or mutation observers"
08:15 <whsieh> johanneswilm: there also isn't a really strong motivation for this (no project is asking for this)
08:15 <whsieh> dandclark: agree, compat risk may be more effort than it's worth
08:15 <whsieh> dandclark: recommend tabling
08:15 <whsieh> zcorpan: seems reasonable
08:15 <whsieh> zcorpan: ..especially if mutation observer is viable workaround
08:17 <whsieh> johanneswilm: so IIRC the motivation for this is that we should've standardized how input events happen in cE w.r.t. target ranges
08:19 <whsieh> johanneswilm: resolution (for time being) — table this issue, wait for FF (masayuki) to follow up

In other words: There is no interest to work on solution for this as workarounds exist and `EditContext` doesn't have this issue. But waiting to hear from @masayuki-nakano and whether we should reopen this issue.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/editing/issues/468#issuecomment-2653451887
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/editing/issues/468/2653451887@github.com>