EditContext: how is bold represented?

[annevk]

The textformatupdate event doesn't seem able to represent a variety of inputs. Am I missing something?

[annevk]

It was pointed out to me this might be based on a misunderstanding of the existing styles, which are there for IMEs. Still, I'm curious to know how styling of text would be mediated through EditContext.

[alexkeng]

EditContext only handles plain texts (it provides plain text view to communicate with OS text input services), so the styling of text like bold, italic, etc, are out of scope of EC, and should be handled by the author's editor model.

The textformatupdate event here is not for styling of the text, it's for the styling of the "decoration" that IME provides to give users hints during the composition, ex showing phrases in Japanese IME (the active phrase has thick underline)

with this information, the author can render the decoration (ex. in a canvas element) to re-create the same IME experience as in normal text input box.

The current spec includes the styles that Windows TSF supports (the TF_DISPLAYATTRIBUTE structure). The spec doesn't support all the styles defined in NSUnderlineStyle on Mac (ex. alternating dashes and dots, NSUnderlineStylePatternDashDot), but those special styles don't seem to be used by IMEs, so the current set of styles should be good.

[annevk]

So this wouldn't be able to integrate with native editing UI per se? E.g., on iOS when editing text you can get this overlay that allows you to bold/italic/underline text, as well as perform other operations. You'd have to reimplement that kind of thing in userland?

[johanneswilm]

When used with contenteditable, it is my understanding that could combine it with the Input Events for formatting changes in order to make use of those native browser menus @annevk mentions. Isn't that right @alexkeng?

[alexkeng]

@johanneswilm, EditContext is not expected to be used with contenteditable, if we attach an EditContext to a contenteditable div, EditContext's behavior will override contenteditable, i.e. the user input won't change DOM, instead it will go to EditContext's text buffer and fire related events.

@annevk, EditContext is designed to be able to integrate with native editing UI like the iOS menu you mentioned. We can think of EditContext as a special version of contenteditable, all the editing heuristics remain the same, e.g. the editing UI, the context menu, etc, the only difference is that the user input now doesn't go to the div and instead it goes to the EditContext. And only after the author's editor model handles the EditContext events and updates the DOM do the users see the characters they type. So back to your question, the native editing UI doesn't need to be reimplemented, but after user apply some command in the menu, e.g. bold, a 'formatBold' input event will be fired, and the authors are responsible to update the DOM accordingly.

[annevk]

I see, so where is it defined that formatBold can be dispatched and what interface it will use, etc.?

[johanneswilm]

@alexkeng I am more confused now. Are you saying that when you attach an EditContext to an element, that element will start emitting beforeinput and input events even though it was not an contenteditable element before? Or where would the formatBold input event come from? When you say "user input" you mean input in terms of typed text input/IME? Not user input in terms of clicking menus or using keyboard shortcuts like CTRL+B, or how is that?

[johanneswilm]

@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

[dandclark]

This diverged onto a couple of different topics that I think have all been resolved elsewhere more recently. For completeness' sake I'll try to address them here. If there are follow-ups, I think it would be best to spin up a separate issues since it's getting hard to track the different threads of conversation here.

I see, so where is it defined that formatBold can be dispatched and what interface it will use, etc.?

The dispatch of beforeinput events against the EditContext editing host element happens in essentially the same way as for other editing hosts such as contenteditable elements, so we can lean on the existing definitions in the input-events spec. See w3c/input-events#145 which updates the beforeinput event default action for EditContext and specifies that while beforeinput fires for EditContext, input does not.

Are you saying that when you attach an EditContext to an element, that element will start emitting beforeinput and input events even though it was not an contenteditable element before?

We have since discussed in EditingWG calls that attaching an EditContext makes the element editable, and makes it emit beforeinput (but not input). I don't have a minutes link handy at the moment but this section of the spec is a good starting point for this: https://w3c.github.io/edit-context/#association-and-activation

How about adding noneditable islands inside of that element using contenteditable=false? How about an island with a lake like the one below?

Nested cases were all addressed here: #53 (comment)