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 ) >>> >>> - 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