On 03/23/2017 05:03 AM, Leif Halvard Silli wrote:
WYSIWYG markup editors have some common problems - which they solve in
various, sometimes confusing, ways. One of these problems is the
question of what should happen if you ‘concatenate’ or join/merge two
elements.
A typical example of what I talk about is the joining/merging of two
XHTML paragraph (<p>) elements or of two XHTML table cell elements:
<p>Foo</p><p>Bar</p>
<th>Foo</th><td>Bar</td>
To join two paragraphs, in then XMLmind XML editor one typically (1)
places the insertion point in front of the word «Bar» and then (2) hits
the Backward Delete key. Then, not only are the two elemetns merged, but
the last and the first word (Foo and Bar, in my example) get joined,
too, and become a single word - which is something the author, in the
end, doesn’t want:
<p>FooBar</p>
When two table cells are joined, one instead uses XMLmind XML editor’s
button for that purpose - but the result is the same:
<th>FooBar</th>
When it comes to merging /paragraphs/, then my word processor in fact
behaves the same way and I, admittedly, never complained about that. Why
is that? It is probably because XMLmind XML editor has one additional
problem that my word processor does not have: In my word processor, the
insertion point /remains/ between "Foo" and "Bar":
<p>Foo<insertionpoint>Bar</p>
Whereas in XMLmind, the insertion point is moved to the start of the
first paragraph:
<p><insertionpoint>FooBar</p>
The difference is that, in my word processor, the lacking white space is
a quick fix - a touch on the Space bar key. Whereas in XMLmind, I must
manually move the insertion point between "Foo" and "Bar" in order to
insert the space character.
However, when my word processor joins two table cells, it will - instead
- place a space character between each joined part (unlike XMLmind, it
can join more than two cells at the time), and it does as well select
the content (this means that, after joining/merging, to delete the text
- I can just start to type; to type in the beginning of the merged cell
- just hit the left arrow key; to type in the end of the merged cell -
hit the right arrow key).
For joining of paragraph elements, the XMLmind developers ought to make
sure the insertion point /remains/ at the same location as does in my
word processor.
You are right, of course. We tried to improve the situation a little bit
by implementing this change:
---
The caret now remains at the same location —between the two joined
fragments— after joining adjacent elements by pressing DEL or BACKSPACE.
---
You'll find this change in XXE v7.4, to be released next week.
This behavior could be /combined/ with the insertion of
a space character: Both when the proposed insertion point behavior is
possible to implement, but at least when it is impossible or illogical
to implement, then - as long as at least one of the joined elements is
a block level element - a space character should be inserted between the
two joined fragments.
(NB: When one joins two table cells, it might not logical to place the
insertion point between between the joined parts - simply because the
backwards deletion key is not what is used to perform the joining of two
cells. However, this is perhaps debatable: As long as XMLmind XML editor
only merges two cells at the time - unlike my word processor, which can
merge several cells, then why not move the insertion point?)
For the rest of the letter, I will explain the ‘space character
insertion behavior’. Namely, when/if it is implemented, when two
elements are joined, we automatically want the following result:
<p>Foo Bar</p>
And we typically want the same result also if we join a block level
element with a inline element:
This: <p>Foo</p><span>Bar</span>
Should become this: <p>Foo Bar</p>
And also if we join a inline element with a block element:
This: <span>Foo</span><p>Bar</p>
Should become this: <span>Foo Bar</span>
And, as well, if we join a block level element with a textual node:
This: <p>Foo</p>Bar
Should become this: <p>Foo Bar</p>
But of course, if we join two inline elements (without any white space
between them) we usually want them to (continue to) be a single word. I
find, however, that it is hard to come up common examples of such usage
(which indicates that is a rather uncommon issue) - but imagine, for
instance, a linguistic text where you want to mark up each syllable in a
word:
This: <span>spell</span><span>ing</span>
Should become this: <span>spelling</span>
The logical conclusion ought to be that when a block level element is
joined with another (block or inline) element, a space character ought
to be inserted (unless either the first elements ends with a whitespacce
character, or the second element begins with a whitespace character)
between the two fragments that get joined. And likewise when a inline
element is joined with a block element.
Only when two inline elements are joined (and may be as well, when two
elements - block or inline - whose content is non-textual - rather
uncommon for a textual oriented editor like XMLmind) should a whitespace
/not/ be added between the two joined fragments. (NB: Special care must
be taken for inline block elements - may be they typically should be
treated like block elements, for the problem that we discuss.)
This, in turn, means that XMLmind XML editor needs to know whether
whether the elements are blockline or inline. And - by the way - this
behavior is really not spesific to WYSIWYG editors - the suggested
behavior could/should be implemented in code editors as well including
in the source mode of the XMLmind editors.
In a summary: The common thing is that space character insertion is
needed when two elements are joined/mergd. Sometimes it is not needed,
but that is the exception.
Thank you for this analysis. It contains some good ideas for further
improving XXE.
--
XMLmind XML Editor Support List
xmleditor-support@xmlmind.com
http://www.xmlmind.com/mailman/listinfo/xmleditor-support
