some points

[holger krekel]

[Christian Stocker Fri, Sep 27, 2002 at 01:41:37AM +0200]

[me]

- Current Cursor-handling (caret browsing) is not good enough
for the end-user. I am afraid implementing a real cursor
that appears right with 'space', 'return' and so on is of
paramount importance.

no, no, no :) Caret Browing is the only way to implement this in a more
or less proper way. Before Caret Browsing we had our own cursor and it
was a real pain and mess.

How did you try to do the cursor, then?

I think we *have* to find a better cursor implementation. It's very
confusing for the end-user to not get feedback on e.g. "space" and "return".
I know it looks like a lot of effort for a minor feature.
Except it isn't a minor feature :-)

And do the other browsers have Caret browsing too, by the way?

regards,

holger

[Reinhard Hess]

Post by holger krekel
[Christian Stocker Fri, Sep 27, 2002 at 01:41:37AM +0200]

[me]

- Current Cursor-handling (caret browsing) is not good enough
for the end-user. I am afraid implementing a real cursor
that appears right with 'space', 'return' and so on is of
paramount importance.

no, no, no :) Caret Browing is the only way to implement this in a more
or less proper way. Before Caret Browsing we had our own cursor and it
was a real pain and mess.

How did you try to do the cursor, then?
I think we *have* to find a better cursor implementation. It's very
confusing for the end-user to not get feedback on e.g. "space" and "return".
I know it looks like a lot of effort for a minor feature.
Except it isn't a minor feature :-)
And do the other browsers have Caret browsing too, by the way?
regards,
holger
--

Hi Christian

We did some testing here at ETH and we fully support Holgers opinion.
The current cursor behaviour is a major problem/bug. It is not yet
deliverable to end users.

regards,

Reinhard
--
Reinhard Hess
Email: ***@id.ethz.ch
Phone: [phone]
Fax: [phone]
ETH Zuerich
Informatikdienste Technologie- und Informationsmanagement
ETH-Zentrum WEP J17
Weinbergstrasse 109
CH-8092 Zuerich

[Michael Slattery]

Folks.

The cursor is important, but I think there is little choice but to see
what the browsers bring us. I'd like to see more docs and examples
first! The readme really does get one off to a good start though.

http://xopus.org/demo/index.html
has the same behavior on my osx laptop, and I've seen no good solution
for having a cursor in an editable region or innerHTML chunk.

http://admin.demo.callistocms.com/.cms/
manages around this by forcing each editable region to be a mini form,
which is a different way of building a page.

There are pluses and minuses to each type, but those like bitflux and
xopus may end up winning, because they feel more like composition and
less like assembly. What clues are out there to help get us a cursor?

Thanks for bitflux,
Mike

Post by Reinhard Hess

Post by holger krekel
[Christian Stocker Fri, Sep 27, 2002 at 01:41:37AM +0200]

[me]

- Current Cursor-handling (caret browsing) is not good enough
for the end-user. I am afraid implementing a real cursor
that appears right with 'space', 'return' and so on is of
paramount importance.

no, no, no :) Caret Browing is the only way to implement this in a more
or less proper way. Before Caret Browsing we had our own cursor and it
was a real pain and mess.

How did you try to do the cursor, then?
I think we *have* to find a better cursor implementation. It's very
confusing for the end-user to not get feedback on e.g. "space" and "return".
I know it looks like a lot of effort for a minor feature.
Except it isn't a minor feature :-)
And do the other browsers have Caret browsing too, by the way?
regards,
holger
--

Hi Christian
We did some testing here at ETH and we fully support Holgers opinion.
The current cursor behaviour is a major problem/bug. It is not yet
deliverable to end users.
regards,
Reinhard
--
Reinhard Hess
Phone: [phone]
Fax: [phone]
ETH Zuerich
Informatikdienste Technologie- und Informationsmanagement
ETH-Zentrum WEP J17
Weinbergstrasse 109
CH-8092 Zuerich
--
bx-editor-dev mailing list
http://lists.bitflux.ch/cgi-bin/listinfo/bx-editor-dev

[Christian Stocker]

Hi

I'm currently in the middle of Silicon Valley and the hotels here have
of course Internet access :) The reason, why I'm here is, that I will
meet the Netscape developers tomorrow and I hope, I can bring some
issues up, which you just mentioned. If you have more stuff, you still
have a few hours time to send me them (approx. 10am PDT = 19:00 CEST).

Post by Michael Slattery
The cursor is important, but I think there is little choice but to see
what the browsers bring us. I'd like to see more docs and examples
first! The readme really does get one off to a good start though.

I also really think, we can't do much about the cursor. The
"space/return" issue can certainly be solved on the javascript level,
but I think, it's time for "Content Editable" on Mozilla and I will
again bring this topic up tomorrow in the meeting.

Doing the cursor in another way is more or less a "no go area" for me.
We had a selfmade-cursor before and believe you me, the old one was
really nothing you would call a well-behaving cursor in todays gui-world
:) But this does certainly not mean, the way it is know couldn't be
better and it will get better and we're always open to new ideas

Concerning docu. I think for wider acceptance/adoptions of BXE,
documentation and simpler examples are very important. I started with a
very simple XHTML based example and I hope, I will have it finished soon
after being at home.

Post by Michael Slattery
How did you try to do the cursor, then?

Completetly in JS, moving span nodes... was terrible, you couldn't move
up/down for example, doubleclicking on words for marking them would have
needed a lot of code, etc... maybe there are better ideas, but some
things are just not doable in JS.

But I will discuss that with the Netscape guys tomorrow. Howeever we
won't have something directly in Netscape/Mozilla in short time, not
before 1.3 certainly.

Post by Michael Slattery
I think we *have* to find a better cursor implementation. It's very
confusing for the end-user to not get feedback on e.g. "space" and "return".

yep, the space/return issue should be solvable, the "no cursor outside
of editable fields" issue with some effort, too. Are there any other
issues, which you guys don't like about the current cursor? If these are
the only problems you have with it, we should be able to solve it even
without the help of Netscape Engineers (but it would certainly make it
easier with them). If there are other, more difficult problems, it would
be great, if you could post them here very soon, so I can discuss them
with the Netscape-people

Post by Michael Slattery
I know it looks like a lot of effort for a minor feature.

No no, I agree with you. The cursor is a very, maybe even the most
important feature of an editor.

Post by Michael Slattery
And do the other browsers have Caret browsing too, by the way?

The only other browser BXE will ever work on (in the foreseeable future)
is MSIE 6 and this one has the contentEditable feature and therefore we
won't need Caret Browsing.

chregu

[holger krekel]

Hi Christian,

Post by Christian Stocker
I'm currently in the middle of Silicon Valley and the hotels here have
of course Internet access :) The reason, why I'm here is, that I will
meet the Netscape developers tomorrow and I hope, I can bring some
issues up, which you just mentioned. If you have more stuff, you still
have a few hours time to send me them (approx. 10am PDT = 19:00 CEST).

Post by Michael Slattery
The cursor is important, but I think there is little choice but to see
what the browsers bring us. I'd like to see more docs and examples
first! The readme really does get one off to a good start though.

I also really think, we can't do much about the cursor. The
"space/return" issue can certainly be solved on the javascript level,
but I think, it's time for "Content Editable" on Mozilla and I will
again bring this topic up tomorrow in the meeting.
Doing the cursor in another way is more or less a "no go area" for me.
We had a selfmade-cursor before and believe you me, the old one was
really nothing you would call a well-behaving cursor in todays gui-world
:) But this does certainly not mean, the way it is know couldn't be
better and it will get better and we're always open to new ideas

Did you consider inserting/inlining a character or image which looks
to the user like a cursor? It should be possible to place a character
(marked up and CSSed) exactly where the next input-character would be.

Post by Christian Stocker
Concerning docu. I think for wider acceptance/adoptions of BXE,
documentation and simpler examples are very important. I started with a
very simple XHTML based example and I hope, I will have it finished soon
after being at home.

Very good! Right now, it's a tad hard to test silva/BXE problems because
i can't really reproduce the problems on the "example"-BXE cvs-version.
I really want to have simple editing (with simple xml) working before
diving into more complex stuff. Otherwise i guess it would be a
months-long fight for getting reasonable stability (in the eye of
the user).

regards and have fun in hotel california,

holger

[Christian Stocker]

Post by holger krekel

Post by Christian Stocker
Doing the cursor in another way is more or less a "no go area" for me.
We had a selfmade-cursor before and believe you me, the old one was
really nothing you would call a well-behaving cursor in todays gui-world
:) But this does certainly not mean, the way it is know couldn't be
better and it will get better and we're always open to new ideas

Did you consider inserting/inlining a character or image which looks
to the user like a cursor? It should be possible to place a character
(marked up and CSSed) exactly where the next input-character would be.

That's exactly what we did before. And it is really no alternative as
mentioned in a mail yesterday (no moving one line up/down possible for
example). I still think, the whole problem has to be solved within
Mozilla itself and not with some crude JS hack :) Nevertheless we'll try
to do this hack as good as possible, so that BXE has good cursor support
for the time being.

Post by holger krekel

Post by Christian Stocker
Concerning docu. I think for wider acceptance/adoptions of BXE,
documentation and simpler examples are very important. I started with a
very simple XHTML based example and I hope, I will have it finished soon
after being at home.

Very good! Right now, it's a tad hard to test silva/BXE problems because
i can't really reproduce the problems on the "example"-BXE cvs-version.
I really want to have simple editing (with simple xml) working before
diving into more complex stuff. Otherwise i guess it would be a
months-long fight for getting reasonable stability (in the eye of
the user).

The XHTML example will be one of the first things I'll do, when I'm back
in Switzerland.

chregu

[holger krekel]

[Christian Stocker Wed, Oct 02, 2002 at 10:23:07AM -0700]

Post by Christian Stocker

Post by holger krekel

Post by Christian Stocker
Doing the cursor in another way is more or less a "no go area" for me.
We had a selfmade-cursor before and believe you me, the old one was
really nothing you would call a well-behaving cursor in todays gui-world
:) But this does certainly not mean, the way it is know couldn't be
better and it will get better and we're always open to new ideas

Did you consider inserting/inlining a character or image which looks
to the user like a cursor? It should be possible to place a character
(marked up and CSSed) exactly where the next input-character would be.

That's exactly what we did before. And it is really no alternative as
mentioned in a mail yesterday (no moving one line up/down possible for
example). I still think, the whole problem has to be solved within
Mozilla itself and not with some crude JS hack :) Nevertheless we'll try
to do this hack as good as possible, so that BXE has good cursor support
for the time being.

Is it really impossible to get to any information about the rendered
objects? Don't you need to know where the cursor is in order to make
something bold etc.? Or process an input event to put a character into the
xml and rerender? Or is the BXE working in a completly different way?
I would think there *has* to be some positional information which could
form the basis for the prescribed cursor.

Post by Christian Stocker

Post by holger krekel

Post by Christian Stocker
Concerning docu. I think for wider acceptance/adoptions of BXE,
documentation and simpler examples are very important. I started with a
very simple XHTML based example and I hope, I will have it finished soon
after being at home.

Very good! Right now, it's a tad hard to test silva/BXE problems because
i can't really reproduce the problems on the "example"-BXE cvs-version.
I really want to have simple editing (with simple xml) working before
diving into more complex stuff. Otherwise i guess it would be a
months-long fight for getting reasonable stability (in the eye of
the user).

The XHTML example will be one of the first things I'll do, when I'm back
in Switzerland.

Good, but i hope we still have enough time to figure stuff out before
the 12th when the new silva/BXE integration release should be ready for ETH.

nevertheless some nice days,

holger

[Christian Stocker]

Hi

Back from Holidays and back into 20°C less :) I won't answer everything
today, as I have to cure my jet-lag...

Post by holger krekel
Is it really impossible to get to any information about the rendered
objects? Don't you need to know where the cursor is in order to make
something bold etc.? Or process an input event to put a character into the
xml and rerender? Or is the BXE working in a completly different way?
I would think there *has* to be some positional information which could
form the basis for the prescribed cursor.

Of course you can get the position of the cursor within a node, meaning
for example between which letters the cursor is. We also can get some
information about the rendered objects, for example width and height and
position, but we can't get the information on which line the cursor is
and which letter is "above" the cursor. This is just one issue we had
with the self-grown cursor, therefore I still think we have to stick to
the Caret Browser Mode for the time being

Buuut, my Netscape visit last week revealed that they are really hard
working on ContentEditable support. It won't be in 1.2 (IIRC), but 1.3
would be a viable target. I hope, this will resolve some issues with the
cursor, but I'll try to improve it nevertheless.

Post by holger krekel

Post by Christian Stocker

Post by holger krekel

Post by Christian Stocker
Concerning docu. I think for wider acceptance/adoptions of BXE,
documentation and simpler examples are very important. I started with a
very simple XHTML based example and I hope, I will have it finished soon
after being at home.

Very good! Right now, it's a tad hard to test silva/BXE problems because
i can't really reproduce the problems on the "example"-BXE cvs-version.
I really want to have simple editing (with simple xml) working before
diving into more complex stuff. Otherwise i guess it would be a
months-long fight for getting reasonable stability (in the eye of
the user).

The XHTML example will be one of the first things I'll do, when I'm back
in Switzerland.

Good, but i hope we still have enough time to figure stuff out before
the 12th when the new silva/BXE integration release should be ready for ETH.

OMG :) Please could you let me know your deadlines a little bit earlier
next time, I could maybe adjust my priorities then (but I wouldn't
cancel my holidays anyway :) )

chregu

[holger krekel]

hello Christian,

welcome back to europe.

Post by Christian Stocker

Post by holger krekel
Is it really impossible to get to any information about the rendered
objects? Don't you need to know where the cursor is in order to make
something bold etc.? Or process an input event to put a character into the
xml and rerender? Or is the BXE working in a completly different way?
I would think there *has* to be some positional information which could
form the basis for the prescribed cursor.

Of course you can get the position of the cursor within a node, meaning
for example between which letters the cursor is. We also can get some
information about the rendered objects, for example width and height and
position, but we can't get the information on which line the cursor is
and which letter is "above" the cursor. This is just one issue we had
with the self-grown cursor, therefore I still think we have to stick to
the Caret Browser Mode for the time being

I understand completly that the issues you are fighting are not easy at
all. But often *users* react quite ignorant of low-level technical
problems. If Notepad can do it, why can't this program do it?

In the meantime i also analyzed the situation with a (javascript-)
friend and he stated that working XML/DOM-based with current
brwosers forces one to hack around lots of bugs. And some things like
cursors are *hard* to do at all. And we are not even talking about
cross-browser here. There is no stable javascript-editor currently
which doesn't mean we shouldn't aim for one. The only solutions so
far seem to involve java.

Post by Christian Stocker
Buuut, my Netscape visit last week revealed that they are really hard
working on ContentEditable support. It won't be in 1.2 (IIRC), but 1.3
would be a viable target. I hope, this will resolve some issues with the
cursor, but I'll try to improve it nevertheless.

Good news. So taking everything into account, the main question probably is
how much time to get a *stable* user-friendly basic WYSIWYG-editor? I don't
want to press on you at all because i know you are doing good work. But it'
s important to have a *realistic* time schedule. Both of us need a reasonable
plan for our customers.

Probably you know that having simple clean code also has a lot more
chance to attract more developers. ASFAIK we will meet on the 16th
in Zuerich so we can discuss this in depth :-)

and sorry for not telling about possible deadlines. I wrongfully
thought that you knew it.

have a good re-calibration,

holger

[Brian King]

Post by Christian Stocker
Buuut, my Netscape visit last week revealed that they are really hard
working on ContentEditable support. It won't be in 1.2 (IIRC), but 1.3
would be a viable target. I hope, this will resolve some issues with the
cursor, but I'll try to improve it nevertheless.

And just to prove it:

http://bugzilla.mozilla.org/show_bug.cgi?id=97284#c109

- Brian

[holger krekel]

[Brian King Wed, Oct 09, 2002 at 06:30:47PM +0100]

Post by Brian King

Post by Christian Stocker
Buuut, my Netscape visit last week revealed that they are really hard
working on ContentEditable support. It won't be in 1.2 (IIRC), but 1.3
would be a viable target. I hope, this will resolve some issues with the
cursor, but I'll try to improve it nevertheless.

http://bugzilla.mozilla.org/show_bug.cgi?id=97284#c109

Judging from Comment #109 on that page i'd say that it might still take
some month for a beta. This comment comes from the assigned developer,
Charles Manke from netscape, and is from 2002-10/8:

We are working hard on this!
We need to fulfill basic embedding requirements such as "removing
editorshell" (architexture restructuring) and conversion to
command-oriented API, then we'll be able to make the jump to
"in place editing" or what I like to call it, "editing everywhere."

That sounds really promising from a development's perspective.

But it could take a year until a mozilla version supports this in
a stable way. This could mean that the integration with the Silva-CMS
would have to stay for a longer time in alpha-status. Does anyone else on
the list have experience deploying Bitflux in a larger environment?

regards,

holger

[Christian Stocker]

Post by holger krekel
[Brian King Wed, Oct 09, 2002 at 06:30:47PM +0100]

Post by Brian King

Post by Christian Stocker
Buuut, my Netscape visit last week revealed that they are really hard
working on ContentEditable support. It won't be in 1.2 (IIRC), but 1.3
would be a viable target. I hope, this will resolve some issues with the
cursor, but I'll try to improve it nevertheless.

http://bugzilla.mozilla.org/show_bug.cgi?id=97284#c109

Judging from Comment #109 on that page i'd say that it might still take
some month for a beta. This comment comes from the assigned developer,

http://bugzilla.mozilla.org/show_bug.cgi?id=97284#c114 (just submitte)

says something different :) And if I recall it correctly, they said the
same to me back then in the meeting (But maybe they said also, it won't
make it into 1.2 but just after that..)

If it's really that short before introduction, then there's really the
question, if it's worth to put time into making a better cursor into
"older" versions. But as we don't know when and how it will be
introduced, we should at least try to improve the most annoying stuff.

chregu

Post by holger krekel
We are working hard on this!
We need to fulfill basic embedding requirements such as "removing
editorshell" (architexture restructuring) and conversion to
command-oriented API, then we'll be able to make the jump to
"in place editing" or what I like to call it, "editing everywhere."
That sounds really promising from a development's perspective.
But it could take a year until a mozilla version supports this in
a stable way. This could mean that the integration with the Silva-CMS
would have to stay for a longer time in alpha-status. Does anyone else on
the list have experience deploying Bitflux in a larger environment?
regards,
holger
--
bx-editor-dev mailing list
http://lists.bitflux.ch/cgi-bin/listinfo/bx-editor-dev