Robin, thank you for your efforts regarding whitespace issues in mozilla
and ns6 composer. It is chock full of problems, as you point out.
Unfortunately the person most responsible for responding to this issue,
me, was away from web connectivity over the last week. Sorry for the
delay in response.
> I have spent most of this week trying to sort out the persistent
> whitespace bugs in Composer. I tried rewriting the ConvertWhitespace
> algorithm, but this turns out to be insufficient. [Robin Whittle]
You are right, it is insufficient. Ignoring the separate (but still
serious) issues of saving out the document through the serializer, and
then reading it back in again, merely loading and editing a document in
composer messes up whitespace frequently.
When you insert text into a document in composer, there are three
different catagories of whitespace to worry about. First, there is
whitespace already in the document, possibly adjacent to where you are
inserting, that does not render: such as certain whitespace around tags
in the html source of the original document. Then, there may also be
whitespace that does render, but which is not "normalized" to the scheme
of alternating spaces+nbsps that you noticed in composer. Finally,
there is whitespace that you may be trying to insert, from a text
source, which may need to be remapped into a sequence of spaces+nbsps in
order to render in html as the same number of spaces that you are trying
to insert.
Composer currently tries to post process the portion of the document
touched by some editor actions, with the intent of remapping whitespace
to the spaces+nbsps needed to make them render. This is too late. At
this point, you can no longer tell which spaces are new and which
aren't, and which were meant to correspond to rendered whitespace and
which were invisible formatting whitespace.
I am in the process of rewriting how whitespace issues are handled in
composer to fix this problem. The idea is to do the work of remapping
any whitespace as we insert text, or breaks, or anything else, and also
as we delete text or breaks or anything else. The goal is for the user
to get the visual behavior they expect when typing, deleting, or pasting
whitespace, and yet to also honor the original formatting of the
document as much as possible.
> This also discusses the current ConvertWhitespace algorithm:
>
> Number of spaces: - = space
> n = non-breaking space
> 1 -
> 2 -n
It is supposed to be:
2 n-
If it isn't that's a bug.
> 3 -n-
> 4 -nn-
> 5 -n-n-
> 6 -nn-n-
> 7 -n-n-n- etc.
>
> and a new one I wrote, which is the same as N4.x, I think:
>
> 1 - or n if this is the first char of the search area.
> 2 n-
> 3 nn-
> 4 nnn-
> 5 nnnn- etc.
I can understand why you might propose this, since given the current
state of composers whitespace handling, your proposal may have the
advantage of fixing certain common classes of whitespace problems. But
the true causes of our problems are separate from this choice of
whitespace mappings, as I think you have already discovered.
So choosing between these mappings is something we can discuss
separately after the real problems are fixed.
--
jfrancis .com -and- moose .net
@netscape @ricochet
