Re: [w3c/editing] EditContext: how is bold represented? (Issue #368)

@alexkeng right now, the way the input events spec is written, the kind of **editing host** that is being used influences a bit how the events are used. The spec only mentions contenteditable, input type "text" and textarea [1]. Now if this is to work like an editing host without being one of those three, then we probably need to mention that somewhere. Is it to behave exactly like contenteditable when it comes to (before)input events? So that means that some OSes will show the bold, underline, etc. menus when it obtains focus? Is there any way to turn those off or individual menu items off? How about the options provided with contenteditable-disabled? Is that to be integrated in some way? 

I see that setting `spellcheck=false` or `spellcheck=true` on the element will work the way they do with contenteditable? How about adding noneditable islands inside of that element using contenteditable=false? How about an island with a lake like the one below?

```
<div contenteditable="true">
<p>blablabla...</p>
<figure contenteditable="false">
<img src="...">
<figcaption contenteditable="true">The caption of the figure</figcaption>
</figure>
<p>blablabla...</p>
</div>
```

Until now it was my understanding that all these extra formatting menus, input events, etc. would only appear if an element is both an EditContext AND a contenteditable element at the same time. If that is not the case, then I wonder exactly how that would work.


[1] https://w3c.github.io/input-events/#overview

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

Message ID: <w3c/editing/issues/368/1013462778@github.com>

Received on Friday, 14 January 2022 20:47:27 UTC