I'm still digesting scottydm's very interesting post.
In the meanwhile, I wonder whether this approach isn’t over-complicating the
matter? My assumption was always that the margin is inviolate. When I hit it,
it’s a brick wall and I have to start again at the next line. This is surely
what the naïve user would expect?
To add to that I would say that having space characters in the margin, and even
worse, invisible space characters in the limbo of the ‘grey area’ is another
fundamental breakdown in wysiwyg. How are you supposed to edit them?
I would do it like this:
1: the cursor is at the end of the line ie against the margin, after typing a space.
a) the next character is non-space: move to the next line, and show the non-space
b) the next character is a space: move to the next line, and show the space.
2: the cursor is at the end of the line after typing a non-space
a) the next character is non-space: restart the whole word on the next line,
leaving the last space dangling on this line. If the word is longer than the
line, just split it before this character.
b) the next character is space: leave it dangling at the end of the line and
move the cursor to the start of the next line.
If in the 1b case the user continues typing spaces, you continue showing them -
just as many as he wants. I can't see any good reason to do otherwise, and all
the alternatives I can see ultimately result in a wysiwyg failure.
Hyphenation occurs when this word is completed and obviously may result in
different line endings.
This approach seems to me to avoid all questions of what you do with the margin
(which of course may not even exist) and the grey area; to make it immediately
and intuitively obvious to a user what is happening; and to be very simple to
implement. You (and I!) may not like the user typing spaces at the start of a
line, but that’s his choice – we can’t know in advance all possible formats he
wants to achieve – what is important is that he should be able to see everything
he’s done and edit it in a completely predictable manner.
On a couple of other points raised:
- positioning the cursor at the end of the line: I think this is fine, but it
should be treated in all respects as though it were actually positioned at the
start of the next. [I think that's what scotty said.]
- justification: here I think the basic principle is that all leading and
trailing spaces are hidden - they should take no part in the calculation.
Similarly with centred text. [Ditto]
I'm still digesting scottydm's very interesting post.
In the meanwhile, I wonder whether this approach isn’t over-complicating the
matter? My assumption was always that the margin is inviolate. When I hit it,
it’s a brick wall and I have to start again at the next line. This is surely
what the naïve user would expect?
To add to that I would say that having space characters in the margin, and even
worse, invisible space characters in the limbo of the ‘grey area’ is another
fundamental breakdown in wysiwyg. How are you supposed to edit them?
I would do it like this:
1: the cursor is at the end of the line ie against the margin, after typing a space.
a) the next character is non-space: move to the next line, and show the non-space
b) the next character is a space: move to the next line, and show the space.
2: the cursor is at the end of the line after typing a non-space
a) the next character is non-space: restart the whole word on the next line,
leaving the last space dangling on this line. If the word is longer than the
line, just split it before this character.
b) the next character is space: leave it dangling at the end of the line and
move the cursor to the start of the next line.
If in the 1b case the user continues typing spaces, you continue showing them -
just as many as he wants. I can't see any good reason to do otherwise, and all
the alternatives I can see ultimately result in a wysiwyg failure.
Hyphenation occurs when this word is completed and obviously may result in
different line endings.
This approach seems to me to avoid all questions of what you do with the margin
(which of course may not even exist) and the grey area; to make it immediately
and intuitively obvious to a user what is happening; and to be very simple to
implement. You (and I!) may not like the user typing spaces at the start of a
line, but that’s his choice – we can’t know in advance all possible formats he
wants to achieve – what is important is that he should be able to see everything
he’s done and edit it in a completely predictable manner.
On a couple of other points raised:
- positioning the cursor at the end of the line: I think this is fine, but it
should be treated in all respects as though it were actually positioned at the
start of the next. [I think that's what scotty said.]
- justification: here I think the basic principle is that all leading and
trailing spaces are hidden - they should take no part in the calculation.
Similarly with centred text. [Ditto]
Oh well, that’s my twopennyworth... off to bed!