We have replied to your long off-list message.
The very last part of our answer was:
---
It's issue #4 which worries us the most.
I was able to create a table similar to delete-rectify.xhtml (see
attached my-delete-rectify.xhtml) using the table toolbar alone.
I faced the same problems as you when I naively tried to get rid with
the spanned cells using Edit|Delete or "Table Cell|Increment Row Span".
Even if this is not intuitive (A) using menu item "Table Cell|Decrement
Row Span" on almost all the cells of the row containing "RECTIFY" then
(B) using menu item "Table Row|Delete" worked flawlessly. (See attached
my-delete-rectify-2.xhtml)
We currently don't see how we could improve the behavior of XXE for
issue #4. For now, we can only recommend to stop using XXE table toolbar
when modifying (just *modifying*; creating seems OK) advanced tables and
to use Cmd-L (View|Redraw) liberally.
Sorry. We know that this is really disappointing.
---
---
PS: Our answer also contained this VERY USEFUL TIP: All the commands
found in the table toolbar are repeatable.
For example, if you select "Increment Row Span" on a td, suffice to
press Cmd-A (A like Again) to repeat this command on other td or th.
On 10/23/2016 04:16 AM, Leif Halvard Silli wrote:
I just sent a long message to you off-list, including attachments. The
issues are (mainly) related the procedures that XMLmind follows in order
to keep the conformance requirements for tables (where the problem is
that empty <tr> elements per the HTML specification are non-conforming):
*
Often (but not always, as I documented in that message) XMLmind
refuses to make <tr> elements empty. However, even if, per the HTML
validator, it is a bug to have empty <tr> elements, Web browsers
support this without any problem whatsoever. And I am convinced (at
least I was, before I started to write this message) that authoring
tools, such as XMLmind, do need support this in some way or another.
Because, as an intermediate step, it is sometimes necessary to
create empty <tr> elements. (However, I now tend to think that those
intermediate steps could be handled by XMLmind itself.)
*
Thus, it might be that the current refusal to create empty <tr>
elements actually in principle is the correct solution but that you
need to rework the way it works.
1.
For instance: Imagine that we have a 3 column row which contains 2
cells with rowspan="2" and one cell with rowspan="1". In such a
case, the <tr> on the next line woujld only contain a single cell
element:
|<tr><td rowspan="2">A</td><td rowspan="2">B</td><td>C</td></tr>
<tr><td>X</td></tr> |
2.
Now, what if you want to collapse that last, "splitted" cell (the C
and the X) in the third column into a single cell? You will the
probably select the upper cell and span it to the lower cell,
creating a CX cell. The question is: What should then happen? (The
first thing to say is that XMLmind currently refuses to span that
cell - warning me that doing so would creeate an empty <tr> element.
But ignoring that problem for now, let us image that XMLmind did
allow us to span that cell, what result should we get after the
spanning?)
*
Alternative A) (second row becomes empty):
|<tr><td rowspan="2">A</td><td rowspan="2">B</td><td
rowspan="2">CX</td></tr> <tr></tr> |
*
Alternative B) (second row plus @rowspan automatically get deleted):
|<tr><td>A</td><td>B</td><td>CX</td></tr> |
*
Alternative C) (the bottom td is not deleted - it is simply made
hidden):
|<tr><td rowspan="2">A</td><td rowspan="2">B</td><td
rowspan="2">CX</td></tr> <tr><td hidden="hidden"/></tr> |
*
Thinking about it now, I think that alternative B) is the only real
option since both alternative A) and C) will leave a <tr> which
become essentially invisible, to the author. Which is highly
problematic.
Today, I would have to first copy the content of the X cell and paste it
into the C cell. Then I would have delete the bottom <tr>. Plus that I
would have to remove the rowspan attribute. For me, as author, this
means that there really is no way - that I can see - to do this that
avoids that the table, in some step in the process, becomes invalid.
And this, in turn, means that either XMLmind must allow me to, as an
intermediate step, create invalid tables. Or, failing that, that XMLmind
must take care of the intermediate steps for me.
Because, like I said: Currently, in XMLmind, there is no effective way
to reach from step 1) to step 2 B). Currently, XMLmind will as I told,
in some situations (but not the above situation), create empty <tr>
elements (I described at leaste one example in the offlist message I sent).
Here is the effective way that XMLmind should implement:
* Once one tries to make the C cell span to the next line,
* then XMLmind should, in one go
1. automatically delete the second <tr> and
2. automatically delete the rowspan="2" attributes of the first row
as well (as they are no longer needed and as they would also
make the table non-conforming).
There is probably more I could and should say ... but I hope at least
that this was useful.
Leif Halvard Silli wrote:
By the above code can be used to demonstrate the situation in which XMLmind currently
creates an empty <tr> element. (Also, see the attached file.)
Namely: If, in XMLmind, you decide to delete that X cell, then XMLmind will allow you
to do that - without any warning. The result is an empty <tr> element. Which
renders the table non-conforming. Without any warning from XMLmind.
Leif Halvard Silli wrote:
What should happens is this: Once you delete the X cell, then the, now empty, <tr> should
also be delted. Plus that the, now, irrelevant (and now also non-conforming)
rowspan="2" attributes should be deleted as well.
(Btw: It is perhaps debatable whether rowspan="2" should be deleted or whether they should become
rowspan="1". Occationally, I use rowspan as styling hooks (e.g. td[rowspan]{background:magenta}).
For that reason I would argue that it would be better if they became rowspan="1" rather than being
deleted.)
--
XMLmind XML Editor Support List
xmleditor-support@xmlmind.com
http://www.xmlmind.com/mailman/listinfo/xmleditor-support
