Hi Holger
>You could transform the XML on the server side to, say, HTML
>and the client works with it and then sends back the HTML
>to be transform back to the "content"-XML on the server side.
>It's more or less a way of transporting data. It's not so
>much the data format i worry about but the display/interaction
>techniques.
I think we have to explain this issue on several levels, as it doesn't seem
to be clear after our former mails:
Here is a possible toc of a future text which will try to explain it,
We certainly will start our explanations by mail and later put it on the
website;) - which I will come to in my next mail as well.
- Conceptional level
- History: SGML, HTML, CSS, XML
- Present: HTML + CSS
- Future: XML + CSS
- History of Bitflux Editor
- From Serverside transformation to Clientside transformation
- Technical Achievements
- Deeply nested XML
- Performance Issues
- Browser implications
- Differences of Mozilla and IE
- Mozilla, a XML based browser
- IE, a HTML based browser
- Possible Scenarios for IE Version for Bitflux Editor
BTW: Read "Creating Applications with Mozilla" (http://books.mozdev.org/)
>
>> > The main work seems not to be the "transport" but a decent interactive
>> > editor on the frontend. If that is really achievable with
>XML/XSLT/CSS
>> > and the mozilla API than it's a good idea (at least for Mozilla:-)
>>
>> I think, this is really achievable :)
>
>I am not convinced as long as there is no decent cursor and stable
>bold/italics/... markup :-) IMO having wordpad-alike behaviour is
>the goal. As usual, your mileage may vary.
>
The cursor is "VERY" important, we agree and Christian is working on it.
Still it has nothing to do with the above issue.
Best regards
Roger
--
roger fischer | bitflux GmbH | schöneggstrasse 5 | ch-8004 zürich
tel +41 1 240 56 72 | mobil +41 78 607 75 06 | fax +41 1 240 56 71
http://www.bitflux.ch | roger.fischer@xxxxxxxxxx
--
bx-editor-dev mailing list
bx-editor-dev@xxxxxxxxxxxxxxxx
http://lists.bitflux.ch/cgi-bin/listinfo/bx-editor-dev
|
