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

From TPAC 2024 minutes:

> [#468](https://github.com/w3c/editing/issues/468)
> 
> Demo: https://software.hixie.ch/utilities/js/live-dom-viewer/saved/13129 , https://software.hixie.ch/utilities/js/live-dom-viewer/saved/13130 
> Johannes: [explain the issue]
> 
> Anne: will it be a big UI change?
> 
> Olli: not for Firefox
> 
> Johannes: it’s not following the spec because it’s using an input so insert where it’s supposed to only insert text. But it’s inserting an entire element and the element comes out of nowhere
> 
> Anne: we can maybe change the event because it matches the platform behaviour. You should focus what event it should be instead
> 
> Johannes: ok. Maybe we should then have a special kind of 
> 
> Anne: what happen when you do execCommand and then you start typing 
> 
> Johannes: the thing is execCommand isn’t used, I mean, so I dont really know what’s happening, so we would need a different one
> 
> Anne: sorry I don't have enough context about this event. Perhaps we could have a format event? That might be a separate API that like typing start… reset the typing start to match the parent or something
> 
> Ryosuke: firing those events and adding a new type of event. A new API to get that typing information. Then editors have to get updated. I think this could defer to like an Edit or Maintainers. Case 1. You are using contentEditable, you want to retain the behavior that matches the platform; but if the App is, implementing their own code, they have their own text editing, editcontext,
> 
> Simon: in Firefox, the behaviour is different, depending on whether there is remaining text before the cursor
> 
> Megan: basically a style is a different tag, When you don’t have any text that element does exist
> 
> Anne: when the users starts typing, they migh expect it to be italic, but then the editor may prevent it. Once the element disappears from the tree, they also want to be able to reset the cursor, to be upright, when the user starts typing, they know it won’t be italic, and that requires a different solution, that’s why we  might need both, or something else?
> 
> Olli: let’s say in Chrome, which adds this bold back, can you query that? Next time I’m typing here, will I get this extra bolder?
> 
> Ryosuke: query command should be done, state would return
> 
> @@
> 
> Simon: consider the idea of sending a format event when you start typing again, wouldn’t you also need to send a format event when you delete the last character? So that’s to send the states that the format is now gone
> 
> Johannes: when you delete the text, the delete, the last character which deletes the entire bold element, that’s something you have on that event, a target range
> 
> Anne: but that’s no format change 
> 
> Johannes: no, so in deletion, if you did, it’s basically the event you get, the whole bold thing is being deleted, and insert and deletion work slightly differently with the input type, so if you delete an entire element, that includes formatting
> 
> Anne: when you get like the deleted content, it does remove the bold, but you dont get a format change event, so the format is still the same
> 
> Johannes: I understand the underlying model works differently
> 
> RN: one thing we could do in the browser is to leave the element in a contentable, one thing we could consider doing is just not delete in the target range, it will not include the bold element, next is to figure out is this a thing browsers can implement
> 
> Johannes: sounds good 
> 
> Megan: +1 to the idea of keeping the bold and italic element
> 
> Simon: the cursor style depending on the actual DOM, not the internal editing state
> … we will need to send a delete event when you move the cursor
> 
> Johannes: the idea of with the contentEditable was that you can cancel all the before input event and do your DOM changes and you can rely on the browser not making its own dom changes that are not going through beforeinput events.
> …
> 
> RESOLUTION: Chromium/Webkit will check viability of leaving <b>-element in place and sending delete event when caret moves.

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

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