Type the phrase “Highlighted text” and then highlight it (in the default yellow color is fine)
Press to go to the next line
Type the phrase “Bold text” and then mark it Bold
Note: In my MS-Word, both of these text entries, at this point, have the Font “Calibri (Body)”, the Font Size 11, and the Style “Normal”. I will not need to change those for the purposes of this exercise.
Open Notepad and type the uppercase word “TEST”
Select and copy that word to the clipboard
Switch () to MS-Word
Position the insertion point somewhere in the middle of the first (yellow-highlighted) line of text
Right-click, notice that the only Paste Option is “Keep Text Only (T)”, and paste ()
Position the insertion point somewhere in the middle of the second (bold) line of text
Note the result: the word “TEST” is not highlighted.
Position the insertion point somewhere in the middle of the second (bold) line of text
Right-click, notice that, again, the only Paste Option is “Keep Text Only (T)”, and paste ()
Interesting! Here’s an attempt at a conceptual analysis.
We’re expecting a concept that we might call TextProperty that associates a collection of properties with a character, and has various (quite subtle) behaviors, notably that when text is inserted after a character, it is by default given the same properties, unless it brings properties of its own (by being pasted with properties). We would expect the highlighting color of a character to be one of its text properties, but your test suggests it is not, and that there is a Highlight concept that behaves differently. This could be objected to on the grounds of (a) redundancy, since there doesn’t seem to be a need for an additional concept where the purpose (assigning appearance qualities to characters) is the same, and (b) lack of familiarity, because the behavior of the concept seems out of line with similar, familiar concepts like TextProperty.
It would be interesting to see what happens if you paste unformatted text immediately after a comment. In that case, I would expect it to behave differently, and not extend the comment, on the grounds that the Comment concept does in fact have a different purpose.
I examined the OOXML in the .docx file and the distinction seems to be as follows. Bolding, italics, some other things are taken as formatting and when a text-only insert is made inside a run of such things, it is given that same formatting.
In both cases, a single run of text is broken up into three chunks (the TEXT run being separate).
In the highlighting case, it appears that highlighting is not taken as formatting but something imposed over where the highlighting is applied and it only sticks to what it was applied to. In the resulting document the TEXT fragment does not have highlighting but the fragments to the left and right retain the original highlighting.
There may also be a subtle difference with regard to formatting if it is not extended over a complete paragraph, what happened in the bold case. I did not test that.
I did not consult the OOXML specification about this, so I may have a likely story without complete confirmation.
I note that the inference being made is that these Font selections in Word are all of the same kind and there is a character level concept in effect. That’s apparently not the case and maybe the brush symbol is a clue. If you open the Font dialog box, highlighting is not provided as a specifiable Font property, not even a Font Effect or a Text Effect.
There’s clearly a conceptual integrity difficulty here, with regard to the UI and UX.
Thanks @dnj, and @orcmid for investigating the implementation. Now I tried @dnj’s suggested test, too.
On one hand, thankfully, when I copy plain text next to a comment, it is not part of the comment in any way.
But how about this:
I then copied the plain text into the middle of the text commented on. Comments, in Review > “All markup” mode, come with their own “highlighting”, and my plain text gets that highlighting, too. I guess that actually makes sense, on the idea that it becomes part of the text commented on (not part of the comment text, I can confirm).
But that’s not all. If I highlight the text commented on (with the default yellow highlighting), in this “All markup” review mode, the highlighting does not show. If I go back to “Simple markup” mode, then the yellow highlighting shows (and the red “this text has a comment on it”) “highlighting” does not show (as expected – it’s not part of “Simple markup” mode.) But it is not obvious to me why the yellow highlighting shouldn’t show in “All markup” mode. I mean, I can make up an explanation, but it’s not a very strong case.
I tried @TalkAboutQuality’s initial example in Word for Mac (16.58) and it doesn’t have the anomaly that you noted (and that @orcmid confirmed in the XML representation). So perhaps it’s just a bug. Even if it is, though, it reveals that there isn’t a uniform implementation of the TextProperty concept.
Regarding highlighting not showing up inside a comment: I’d call this a concept-to-UI mapping issue, because the highlight does seem to be present but just not displayable (because commenting and highlighting use the same appearance).
BTW, the TextProperty concept is a bit intricate. The general rule is that a character’s text properties set the default for text that follows the character but not text that precedes it. But this rule is not applied uniformly. Newline characters are treated differently: if a line starts with a word in bold, a character added at the start of the line appears in bold too (at least for my versions of TextEdit, Pages, Word and Indesign), and this is unaffected by selecting the newline character and changing its formatting!
This seems to me a reasonable non-uniformity and is a nice example of how concepts evolve over many years to incorporate all kinds of small refinements. It’s interesting that nobody has invented a better concept. Explicitly marking the start and end of formatted regions (as in markdown and in early word processors that used “control codes” such as WordStar) eliminates these problems but introduces other complications.
BTW, a text formatting concept I’m confused about on macOS: in the font dialog box, there is a control for setting text color, underline color and strikethrough color. There is also a control for setting the background color of the text. Here’s what it looks like with the background color set to yellow:
But strangely this is not applied as a character-by-character highlighting color. In TextEdit, it sets the color of the entire document, and in Pages, it sets the color of one or more entire lines. In the toolbar of TextEdit, instead of this control it has one that looks similar but sets the highlight color of whatever characters are selected:
