Re: Cursor Issues to be resolved

Michael Slattery <[email protected]>
Newsgroups gmane.editors.bitflux.devel
Message-ID <[email protected]>
I am in favor of scope reduction in terms of browser support.

The rest will sound like scope explosion, or at least a swap-out:

I still think the short term solution for the cursor is not to try and 
develop a fake cursor in parallel with the moz efforts.
For all of the xopus efforts, their contentEditable doesn't do what 
this group wants.

I believe Christian can get a cursor working, but I feel that if Moz is 
promising something as well, then we should all burn our calories on 
something else.

My personal favorite: let's improve the pop-up supplemental forms we 
already use!   Efforts here will be useful even after the browsers fix 
the cursor.

I think the short term solution is to use pop-up forms the way 
callistocms works.  I know it is a touch more clumsy, but we can give 
the user the option to toggle between in-line and pop-up editing, and 
it is still 500% better than a conventional web app, with all the 
latency and reloads.

The forms based solution could be carved out in a few weeks, it would 
be much more stable and predictable, and could kept on as an alternate 
or supplemental interface, even after the contentEditable control 
becomes real.

The main trade off is that in-line is more elegant when content is 
being entered in a serial fashion - the idea of the default or 'give me 
this element next after I get out of this one'  behavior is brilliant!

The pop-up forms is more efficient when trying to relocate an 
individual element, for example, or changing the element type.   
Already we have to popup secondary forms when metadata or additional 
content is needed, like images or links.    So adding the content to 
primary elements in a pop-up isn't that big a leap.



Please try out
http://admin.demo.callistocms.com/.cms/
demo:demo

and tell me what you like and hate about it.  I will dig in and help to 
get the pop-ups working if there is buy-in here.




On Wednesday, October 9, 2002, at 12:08 PM, Christian Stocker wrote:

> On Wed, 2002-10-09 at 13:15, holger krekel wrote:
>> [Christian Stocker Wed, Oct 09, 2002 at 11:12:32AM +0200]
>>> I'll try to resolve today some of the issues mentioned with the 
>>> cursor.
>>> Here's my annonance list, please complete it, if i forgot something.
>>>
>>> - Hitting space should insert a "visible" space.. (not sure what 
>>> should
>>> happen, if i hit space twice or more. IMHO[1] it should only insert 
>>> one
>>> space, or at least only show one space. CTRL+space could be used for
>>> insert &nbsp;)
>>>
>>> - Hitting return should insert a "visible" new line, before i write
>>> something on the new line...
>>>
>>> - No blinking cursor outside of editable fields.
>>>
>>> - home should go to the start of line (sorry, not possible, start of
>>> editable field could be possible..)
>>
>> these are currently the most important points regarding the cursor.
>> great that you work on it.
>>
>> I'd still be interested in your oppinion on the cross-browserability
>> of caret-browsing, though.  ASFAIK it's very hard but hopefully you 
>> have
>> better news :-)
>
> Maybe we should stop talking about cross-browserbility and introduce 
> the
> more accurate word dual-browserability.... For the foreseeable future,
> BXE will not work on anything other than Mozilla/Gecko and MSIE6 based
> browsers, therefore we just have to take those to codebases into
> account. And MSIE has contentEditable, which should be enough to have a
> decent cursor.
>
> chregu
>
>
>
>
>
> -- 
> bx-editor-dev mailing list
> [email protected]
> http://lists.bitflux.ch/cgi-bin/listinfo/bx-editor-dev
>

-- 
bx-editor-dev mailing list
[email protected]
http://lists.bitflux.ch/cgi-bin/listinfo/bx-editor-dev
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.