need to create decoration of mixed type sort of

I need to create a decoration that has a text field inside with a chrome around the field. The decoration should behave like a mix of mark decoration and a widget/replace decoration. The text field inside should be like a part of the text around the decoration, meaning that cursor navigation should focus the widget and move across the text field and cause the focus to go back to the surrounding text when I move past the edge of the text field. I have attached an animated GIF that demonstrates the feature. @marijn I would appreciate any pointers, specifically, what would be the best approach to implement something like that.
Thanks!
konstantin
decoration

An inclusive mark decoration with :before styling stuff might be able to do this, though that won’t work if you need the visual elements to be interactive. In that case maybe using a mark for the border and a widget for the interactive element would work.

Thanks, @marijn. I am going to use a replace decoration for this feature and emit a contenteditable element from it. This looks similar to creating a mark decoration, because mark decorations add an element inside the main contenteditable element too. The only problem that I see so far is that I will need to implement my own cursor navigation, something similar to View.moveByChar etc. I think that there is no consistency between different browsers in how the cursor moves across contenteditable sub-elements. So I think that your code implements navigation “manually”. How do you recognize such sub-elements when you navigate the cursor? How do you decide where to move the cursor next when you reach an edge of some sub-element? Where is this code? Is this what EditorView::bidiSpans gives you? If I override this method and add my content editable (that I create inside my decoration) in the output, will it be safe to do?

In simple text, browser’s native behavior for cursor motion might be good enough. But you’ll probably need to override it at the boundaries of the element. The editor’s own cursor motion implementation just works in terms of document positions, not DOM elements.