Bug 48302 - khtml support for designMode and contenteditable=true
Summary: khtml support for designMode and contenteditable=true
Status: CONFIRMED
Alias: None
Product: konqueror
Classification: Applications
Component: khtml (show other bugs)
Version: 4.0
Platform: openSUSE Linux
: NOR wishlist
Target Milestone: ---
Assignee: Konqueror Developers
URL:
Keywords:
: 68319 99042 117934 134915 152399 196427 (view as bug list)
Depends on:
Blocks:
 
Reported: 2002-09-26 09:32 UTC by Andreas Hochsteger
Modified: 2009-07-26 04:27 UTC (History)
21 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
proposed WebCore merges and some utilities (41.52 KB, patch)
2003-07-23 23:41 UTC, Leo Savernik
Details
proposed big WebCore merges and some utilities (66.05 KB, patch)
2003-08-05 21:40 UTC, Leo Savernik
Details
very very very very initial caret navigation (231.92 KB, patch)
2003-08-09 04:50 UTC, Leo Savernik
Details
quite complete caret navigation (284.40 KB, patch)
2003-08-18 23:55 UTC, Leo Savernik
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Andreas Hochsteger 2002-09-26 09:32:42 UTC
Version:           4.0 (using KDE 3.0.3)
Installed from:    SuSE
Compiler:          gcc version 2.95.3 20010315 (SuSE)
OS:          Linux (i686) release 2.4.18-4GB

More and more Content Management Systems are using WYSIWYG XML editors like Xopus [1] or Bitflux Editor [2]. To use them, the browser must support to type directly into the displayed page. To enable this, usually you can set the attribute contenteditable=true for a certain tag.
Mozilla didn't support this directly, but there exists a workaround [3] which uses the caret browsing mode of Mozilla (F7), which turns on a cursor, with which you can navigate through the page.

It would sure be of great publicity too, if you could show off a WYSIWYG XML editor running in konqueror and serving powerful XML Content Management Systems (e.g. Wyona [4]).

Imagine using those XML editors, to write KDE (DocBook) documentation or edit other KDE-related XML files whith an easy to use XML editor ;-)

References:
[1] http://xopus.org/
[2] http://www.bitflux.ch/editor/
[3] http://xopus.org/index.jsp?menu=mozce
[4] http://www.wyona.org/
Comment 1 Vedran Ljubovic 2003-06-03 19:26:51 UTC
I'd like to suggest instead implementing designMode property. This property is 
implemented in Mozilla since 1.3: 
http://devedge.netscape.com/viewsource/2003/midas/01/ 
Therefore I believe that serious CMS applications will use designMode. 
On the above URL you can find specifics on Mozilla's implementation compared to 
IE implementation. You can also find some free "cross-browser" scripts. IE supports 
this property since 5.5. 
 
I believe designMode can be implemented using kafka part (Quanta's WYSIWYG 
mode). 
Comment 2 Leo Savernik 2003-06-04 16:28:41 UTC
Why "instead"? contenteditable is but a subset of the designMode property. If   
konq supports designMode, contenteditable should not be too much work to be   
implemented.   
  
After all, CCing Nicolas to indicate the existance of this bug.  
  
Nicolas: Is there any attempt to create a general subset of functionality that 
accomodates the implementation of kafka as well as the implementation of 
designMode/contenteditable? 
Comment 3 Nicolas Deschildre 2003-06-04 18:25:58 UTC
Currently, all the things done to make a cursor appears as well as some basic
editing functionnalities have been done "outside" khtml i.e. a derivated class
from khtml implements the editing functionnalities.
Much of this was possible thanks to the tag definitions of Quanta, where i have
added some editing properties for each Tag, e.g. if it can have the cursor focus
and where, and if the cursor can "enter" inside the tag, and thanks to some
khtml public functions e.g. DOM::Node::GetCursor() and DOM::Node::getRect().
But this implementation has some limits : cursor position sometimes have to be
guessed and thus not always right, and sometimes khtml returns the wrong cursor
position. See http://bugs.kde.org/show_bug.cgi?id=56339
I haven't considered this solution because first it was too hard for me alone to
add such editing capabilities to khtml, and then because i have never heard of
designMode before :)
But if someone implements DesignMode (only the cursor, selection, basic cursor
navigation and backspace/delete support), i would be very grateful to him as it
will be a solution of many of my editing problems, and i imagine the kmail guys
would be happy to add the creation of HTML messages support!
Comment 4 Nicolas Deschildre 2003-06-05 18:30:06 UTC
I will even add that i would be ready to help to add DesignMode support to khtml as the 
kafka part integration into quanta will be soon finished, but can you specify me some 
details about designMode (where is it defined? I didn't find it in the W3C 
recommandations). 
Comment 5 Leo Savernik 2003-06-06 20:32:35 UTC
Rich text editing of web pages is purely nonstandard stuff so far. So there's  
no submission to any standards body (yet). The features of rich text editing  
are defined mainly by the following sources: 
Internet Explorer's contenteditable [1], IE designMode [2] 
and the editing APIs [3]. 
  
Mozilla also supports designMode by the Midas project [4]. 
Midas is more powerful than IE's designMode. The only thing moz still lacks is  
contenteditable which this bug is all about.  
  
I'd like to make the following proposals for a designMode/contenteditable  
implementation:  
  
- support designMode as of Midas spec.  
- support contenteditable, but as css:  
	-konq-user-editable: { true | false } | inherit  
where inherit is default.  
contenteditable is then emulated by simple rules in khtml.css:  
	*[contenteditable="true"] { -konq-user-editable: true }  
	*[contenteditable] { -konq-user-editable: false }  
	*[contenteditable="inherit"] { -konq-user-editable: inherit }  
  
Furthermore I think that konq should *not* support the IE API [3] but fully 
rely upon the DOM2-Range [5] standard for content manipulation. However, I 
don't know whether konq features a useable (and fast) DOM2-Range 
implementation. 
 
Those are merely some suggestions. I'd really like to become involved with the 
implementation of rich text editing, but I'm overburdened now and cannot do any 
development work before late July. If you could give the implementation a start 
before that date I'd be happy. 
 
References: 
[1]http://msdn.microsoft.com/workshop/author/dhtml/reference/properties/contenteditable.asp  
[2]http://msdn.microsoft.com/workshop/Author/dhtml/reference/properties/designMode.asp  
[3]http://msdn.microsoft.com/workshop/browser/mshtml/overview/intromarkupsvc.asp 
[4]http://mozilla.org/editor/midas-spec.html  
[5]http://www.w3.org/TR/2000/REC-DOM-Level-2-Traversal-Range-20001113/ranges.html 
Comment 6 Jan Ulrich Hasecke 2003-07-11 15:23:25 UTC
I am using Zope/CMF/Plone as CMS and there are several rich text editors. One 
is called Epoz and works with mozilla and ie. I does not really like mozilla 
but this is a nice feature. As I have heard it is based on midas: 
 
http://www.mozilla.org/editor/midas-spec.html 
 
I would be happy if I could use konqueror when editing my sites. Konqueror is 
marvelous! 
 
Thanks! 
Comment 7 Leo Savernik 2003-07-11 15:40:54 UTC
I'm going to work on it this summer.  
  
Changing title to reflect what I'm really going to do (removing XML editor 
because designMode is restricted to html only; luckily khtml is a css based 
renderer so it can be extended to generic xml one day, too). 
 
Comment 8 Leo Savernik 2003-07-18 21:21:29 UTC
Now I'm really working on it. 
 
Taking. 
 
Comment 9 Leo Savernik 2003-07-23 23:41:22 UTC
Created attachment 2053 [details]
proposed WebCore merges and some utilities

A patch that contains the merges from WebCore and small additions I'll need for
caret navigation. 

This is only for review, *not* for commit.
Comment 10 Leo Savernik 2003-08-05 21:40:12 UTC
Created attachment 2161 [details]
proposed big WebCore merges and some utilities

Much bigger merges that incorporate and make persistant the InlineFlowBox
information from WebCore, but least invasive to the existing code.

This patch also contains all changes from the last patch (attachment 2053 [details]),
thus obsoleting it.

This is only for review, *not* for commit.
Comment 11 Leo Savernik 2003-08-09 04:50:09 UTC
Created attachment 2191 [details]
very very very very initial caret navigation
Comment 12 Leo Savernik 2003-08-09 05:11:48 UTC
Subject: [patch] very very very very initial caret navigation

With this huge patch, khtml gets a caret mode (like mozilla's caret mode), 
however, it cannot be activated by gui actions. It compiles against the 
latest CVS (as of 2003-08-09, 4:50 CET DST).

Beware, it is really restricted. Nearly nothing is implemented except very 
basic keyboard navigation. And it's not even working correctly for 
appearently primitive cases (but they aren't if you've seen the 
implementation details)

The reason I'm posting this is to enable the khtml developers to get an idea 
what I'm doing, so please review and comment on the changes.

The next steps are:
1a make caret navigation not suck.
1b make selections cooperate with navigation.
2. implement basic editing.
3. implement drag&drop.
4. implement and fix stuff I've forgotten in the first iterations.

Comment 13 Leo Savernik 2003-08-18 23:55:05 UTC
Created attachment 2269 [details]
quite complete caret navigation

Caret Navigation
=============================

Caret navigation is quite complete now in terms of what the user expects. A fat
explanation for a fat patch.


Overview
-----------------------------

The patch provides the following functionality:
- Activating the caret/updating the caret on relayout
- Keyboard Navigation. All common keys should work as expected, also in
combination with shift to select text.
- Placing the caret by mouse.

There's still no means to activate caret mode by GUI, but I think I'll add an
action soon so that independent people can test it.

All caret related changes are encapsuled in
#ifndef KHTML_NO_CARET
#endif
blocks. Defining this will simply not compile caret mode in (however, I haven't
yet tested it).


Detailed Changes
-----------------------------

A detailed explanation of the changes follows:
In khtml_part:
- new property editable. Toggles whole document editable (when it's
implemented)
- new property caretMode. Toggles caret mode.
- new signal caretPositionChanged.
- Matt Newell's optimization patch for node order determination
- trivia: replaced replace(QRegExp, QString) by replace(QChar, QChar), fixed
typos

In khtmlview:
- main part of caret navigation logic. See architecture.

In testkhtml:
- Added two buttons to toggle editable, caret Mode.

In css/:
- Added new property -konq-user-input: [ enable | disable | none ]

In dom/dom_doc:
- Added property designMode. Functionally equivalent to KHTMLPart::editable.

In dom/dom_element:
- Added property contentEditable. It's a shortcut for inquiring this element's
-konq-user-input value

In dom/dom_node:
- getCursor is deprecated without replacement (If anybody needs this, please
yell).

In html/:
- changed maximum length of attribute names from 14 to 20 (contenteditable is
15, and it took me quite a long time to find out why khtml hadn't recognized
it)
 
In rendering/Makefile.am:
- activated compilation of render_line.cpp

In rendering/bidi:
- merged the Inline*Box changes from Safari in the least intrusive way.

In rendering/font:
- added comments
- added getters for letter spacing and word spacing

In rendering/render_box:
- updated position method
- added caretPos method

In rendering/render_br:
- simplified caretPos implementation (will vanish in a later rev.)

In rendering/render_flow:
- ported over API for line traversal from Safari.
- added special caretPos method.

In rendering/render_image:
- added caretPos method (will vanish in a later rev.)

In rendering/render_line:
- ported from Safari, made compilable.
- added InlineBox::minOffset, InlineBox::maxOffset
- const'ed methods that obviously should be const but weren't

In rendering/render_object:
- ported from Safari: createInlineBox, modified position
- renamed cursorPos to caretPos, and extended parameters
- new methods minOffset, maxOffset

In rendering/render_style:
- added inheritable property EUserInput, accessor RenderStyle::userInput

In rendering/render_text:
- derived TextSlave from InlineBox, and renamed it to InlineTextBox
- made InlineTextBox::checkSelectionPoint correctly handle justified text
- added InlineTextBox::offsetForPoint, finds approximate offset to given
x-coordinate
- added method InlineTextBox::width, which also treats justified text
correctly.
- renamed findTextSlave to findInlineTextBox and fixed it for rare cases when
it would find the wrong text box.
- renamed deleteTextSlaves to deleteTextBoxes

In xml/:
- implementations of the changes in dom/
- NodeImpl: added prevLeafNode, nextLeafNode, minOffset, maxOffset


Architecture
-----------------------------

For navigation purposes, the whole document is treated as a linear list of
lines. Each line itself is composed of one to many inline boxes containing the
actual characters/objects.

As SGML-documents are represented by trees, the line representation is created
ad hoc by the aid of several classes.

LinearDocument:
Represents the whole document as a linear list of lines. It has iterators to
the first line, last line, beginning (before first line), and end (beyond last
line) documents and tries to somewhat resemble STL semantics.

LineIterator:
Iterates through the lines of a LinearDocument object.

EditableLineIterator:
As not every line is necessarily editable, this iterator only delivers those
lines which are deemed to be editable/navigable. Works otherwise just like
LineIterator and is comparable to it.

InlineBoxIterator:
Iterates through the inline boxes of a line.

EditableInlineBoxIterator:
Analogically to EditableLineIterator, this iterator only regards those boxes
that are editable/navigable.

EditableCharacterIterator:
This iterator iterates through all leaf-node characters of the document,
effectively treating it as a linear stream. Non-character elements are treated
as whitespaces.

Btw, these classes are *private*. And it will stay that way. I have yet to come
up with a sensible persistent public API for customizing navigation, but that's
far into the future. The explanations are here for the people who review the
patch (which will be as many as for my last patch, that is: zero ;-) ).


Known Bugs
-----------------------------

Though the suck factor of navigation has become very low, there are still the
following known bugs (to the hundreds of not yet known):
- caret placement by mouse doesn't work reliably.
- movement through tables doesn't work as expected.
- movement through invisible elements is possible (that looks so stupid, you
can't imagine)
- when caret mode is initially activated, the caret does sometimes not move on
the first keypress.


Regressions
-----------------------------

None that I know of.
During the development I had some crashes in the new code, but I think I sorted
them all out. There were *no* crashes in the old code ever, so everything not
relying on navigation should continue working reliably.


Missing Features
-----------------------------

- Editing capabilities.
- Drag & drop.


Fixed Bug
-----------------------------

In the course of implementation I had to fix some bugs which were tolerable for
a read-only browser, but are inacceptable for caret navigation:

#46224 and dupes (but not #50683, must be investigated separately): x-range
mismatches with justified text
Comment 14 Andreas Hochsteger 2003-08-19 06:58:34 UTC
Subject: Re:  khtml support for designMode and contenteditable=true

Leo Savernik wrote:

> Btw, these classes are *private*. And it will stay that way. I have yet to come
> up with a sensible persistent public API for customizing navigation, but that's
> far into the future. The explanations are here for the people who review the
> patch (which will be as many as for my last patch, that is: zero ;-) ).

Leo, I have to tell you, that I read all your messages concerning this 
bug and I'm looking forward to use things like Xopus or bitflux within 
KDE. Unfortunately I don't have the time to test the patch myself :-(

So don't be discouraged, if nobody has the time to review your patch.

I'd suggest that you - when it's possible to activate it with an action 
- put it into CVS (if possible without #ifdefs). Then it's much easier 
to test and you might get more feedback.
Just my 2 Euro-Cents ;-)

Keep up that good work!


Comment 15 Leo Savernik 2003-08-19 11:50:38 UTC
Hello Andi,  
  
I sent the same message to kfm-devel. The part with the reviewers wasn't  
intended to be posted here, but by the time I finished the posting, I had  
already forgotten about it ;-)  
  
For clarification, the patch is meant for a formal review by the khtml core  
developers, not for a functional review by anybody else. I will commit it to  
CVS by the end of this week *at the latest*, then everybody can try the changes  
by updating khtml from CVS head without the hassle of patching anything.  
  
Because you mentioned the ifdefs, they have to be explicitly defined to *not*  
compile the caret stuff. So by default you get full functionality, and I think  
that's what everybody expects.  
  
Regarding xopus.org, this seems to be an IE thingy only. The page is totally 
distorted in konqueror, and hardly useable in Mozilla. I'll never strive for 
100% IE compliance (simply impossible), so I wouldn't count on xopus ever 
working with khtml. 
 
After all, I took me much longer to implement caret navigation than I 
anticipated (and it ain't finished yet). However, I attach importance to a 
seamless, mostly bug-free, least-sucking implementation (remember caret mode of 
Mozilla 1.0, anybody? That's the way *not* to do it). 
 
Then, by 1st Sept., feature freeze hits. I'll still continue work until beta 1 
(by 29th Sept.), and guessing from the prior advance I know that it won't be 
remotely ready for KDE 3.2, mostly for two causes: (1) Beta 1 forbids feature 
commits, (2) holydays are over, real life hits back. So I have yet to see in 
which shape the implementation will be left at the end of September, to decide 
what to do. I *will* implement it, but it takes time. Don't hold your breath 
yet. 
 
Comment 16 Leo Savernik 2003-08-22 02:07:24 UTC
Subject: Re: [Patch] quite complete caret navigation -- committed

Am Dienstag, 19. August 2003 00:00 schrieb Leo Savernik:
> Caret Navigation
[...]

I promised to commit it. Now I've done it.

The main difference between the posted patch and the commit is the 
implementation of sensible navigation through tables.

Caret mode is not yet accessible by GUI/accel in konqueror, so you have to use 
testkhtml.

I tested caret mode on three real-world pages:
http://heise.de/
http://kde.org/
http://linuxtoday.com/

It works best on kde.org (mostly because that's the only well-formed page in 
the test). There are some severe navigation problems on linuxtoday.com. I'm 
perfectly confident that many other real-world pages will exhibit strange 
bugs, too.

If you test it, only report crashes, *no* other bugs because they are yet too 
easy to discover for now.

Comment 17 Leo Savernik 2004-04-15 13:53:18 UTC
CVS commit by savernik: 

Caret Navigation II
=============================

This is a tremendously enhanced version of the caret mode, building upon the latest merges from the WebCore render_line implementation.

Overview
-----------------------------

The caret position now strictly adheres to the DOM Range specification. Therefore, it is now possible to place the caret between two elements by specifying an appropriate offset.

Furthermore, navigation has been enhanced to also allow placement of the caret at the outside of block and inline elements that are indicated (i. e. have a border/are otherwise special).

The code looks like a battlefield, and still has rough edges. Cleanup will follow soon.

Detailed Changes
-----------------------------

	* khtml_caret{.cpp,_p.h}: Vast changes.
	Added classes CaretBox, CaretBoxLine, CaretBoxIterator,
	EditableCaretBoxIterator. Changed every other class.

	* khtmlview.[cpp,h}: (class KHTMLView) Adapt to khtml_caret* changes.
	(KHTMLToolTip::maybeTip) Save tooltip position instead of recalculating it.

	* rendering/render_{inline,box}.{cpp,h}: (Render{Box,Inline}::caretPos)
	Handle outside caret positions.

	* rendering/render_{image,br}.{cpp,h}: Remove superfluous
	Render{Image,BR}::caretPos.

	* rendering/render_line.h: (InlineBox::maxOffset) Return 0 instead of 1.

	* rendering/render_object.{cpp,h}: (RenderObject::caretPos) Introduce
	flags to denote outside positions.
	Add RenderObject::isRenderReplaced.

	* rendering/render_replaced.h: Add RenderReplaced::isRenderReplaced
	returning true.

	* rendering/render_text.{cpp,h}: (RenderObject::caretPos) Handle flags.

	* xml/dom_nodeimpl.{cpp,h}: (NodeImpl::getCaret) Handle DOM Range
	positions.
	Remove unused NodeImpl::{prev,next}LeafNode.
	(NodeImpl::maxOffset) Return child node count instead of 1 for element
	nodes.
	(NodeBaseImpl::childNode): Don't crash on out-of-bounds offsets.

Known Bugs
-----------------------------

Among some smaller negligible bugs, the most disturbing one is broken list item
navigation. I cannot fix it because it's not a bug caused by this patch. I'm working
on a solution.

CCMAIL: 48302@bugs.kde.org


  M +2705 -283 khtml_caret.cpp   1.12
  M +851 -128  khtml_caret_p.h   1.9
  M +116 -75   khtmlview.cpp   1.626
  M +10 -11    khtmlview.h   1.203
  M +78 -2     rendering/render_box.cpp   1.230
  M +2 -2      rendering/render_box.h   1.76
  M +5 -3      rendering/render_br.cpp   1.19
  M +4 -2      rendering/render_br.h   1.25
  M +5 -4      rendering/render_image.cpp   1.134
  M +4 -2      rendering/render_image.h   1.52
  M +57 -0     rendering/render_inline.cpp   1.9
  M +2 -0      rendering/render_inline.h   1.7
  M +1 -1      rendering/render_line.h   1.7
  M +2 -2      rendering/render_object.cpp   1.259
  M +15 -5     rendering/render_object.h   1.183
  M +4 -4      rendering/render_replaced.h   1.73
  M +10 -8     rendering/render_text.cpp   1.244
  M +2 -2      rendering/render_text.h   1.110
  M +28 -64    xml/dom_nodeimpl.cpp   1.232
  M +3 -21     xml/dom_nodeimpl.h   1.155



Comment 18 Leo Savernik 2004-12-13 01:39:08 UTC
CVS commit by savernik: 

Merge of WebCore's caret mode, and contenteditable changes.

With this merge, rudimentary editing of html fragments becomes possible.

The changes are not nearly stable or feature-complete. Hence, design mode
is developed in a branch of its own.

Don't expect contenteditable/design mode to be shipped with KDE 3.4.

The unwary of you may check out the design_mode branch of khtml to get an
impression about the current state and progress.

CCMAIL: 48302@bugs.kde.org


  A            editing/.cvsignore   1.1.2.1
  A            editing/Makefile.am   1.1.2.1
  A            editing/edit_command.h   1.1.2.1 [LGPL (v2+)]
  A            editing/edit_command_adapter.cpp   1.1.2.1 [LGPL (v2+)]
  A            editing/edit_command_adapter.h   1.1.2.1 [LGPL (v2+)]
  A            editing/editing.cpp   1.1.2.1 [LGPL (v2+)]
  A            editing/editing_p.h   1.1.2.1 [LGPL (v2+)]
  A            editing/editor.cpp   1.1.2.1 [LGPL (v2+)]
  A            editing/editor.h   1.1.2.1 [LGPL (v2+)]
  A            editing/editor_command.h   1.1.2.1 [LGPL (v2+)]
  A            editing/htmlediting.cpp   1.1.2.1 [UNKNOWN]
  A            editing/htmlediting.h   1.1.2.1 [UNKNOWN]
  A            editing/htmlediting_impl.cpp   1.1.2.1 [UNKNOWN]
  A            editing/htmlediting_impl.h   1.1.2.1 [UNKNOWN]
  A            editing/jsediting.cpp   1.1.2.1 [UNKNOWN]
  A            editing/jsediting.h   1.1.2.1 [UNKNOWN]
  A            misc/khtml_partaccessor.h   1.1.2.1 [LGPL (v2+)]
  A            xml/dom_position.cpp   1.1.2.1 [UNKNOWN]
  A            xml/dom_position.h   1.1.2.1 [UNKNOWN]
  A            xml/dom_positioniterator.cpp   1.1.2.1 [UNKNOWN]
  A            xml/dom_positioniterator.h   1.1.2.1 [UNKNOWN]
  A            xml/dom_selection.cpp   1.1.2.1 [UNKNOWN]
  A            xml/dom_selection.h   1.1.2.1 [UNKNOWN]
  M +299 -0    ChangeLog   1.353.2.1
  M +2 -1      Makefile.am   1.162.2.1
  M +10 -9     khtml_events.cpp   1.17.8.1
  M +3 -0      khtml_iface.cc   1.10.6.1
  M +710 -189  khtml_part.cpp   1.1063.2.1
  M +120 -7    khtml_part.h   1.270.2.1
  M +1 -0      khtmlimage.cpp   1.44.2.1
  M +21 -49    khtmlpart_p.h   1.60.2.1
  M +149 -65   khtmlview.cpp   1.674.2.1
  M +12 -5     khtmlview.h   1.215.2.1
  M +4 -1      css/css_valueimpl.h   1.57.2.1
  M +48 -0     dom/dom_doc.cpp   1.56.4.1
  M +12 -0     dom/dom_doc.h   1.44.2.1
  M +0 -12     dom/dom_element.cpp   1.49.2.1
  M +17 -0     dom/html_element.cpp   1.25.8.1
  M +30 -0     dom/html_element.h   1.25.2.1
  M +31 -0     ecma/kjs_dom.cpp   1.182.2.1
  M +4 -2      ecma/kjs_dom.h   1.72.2.1
  M +9 -0      ecma/kjs_html.cpp   1.279.2.1
  M +2 -1      ecma/kjs_html.h   1.82.2.1
  M +42 -0     html/html_elementimpl.cpp   1.182.2.1
  M +4 -0      html/html_elementimpl.h   1.76.2.1
  M +1 -3      html/html_inlineimpl.cpp   1.137.2.1
  M +2 -0      html/htmltokenizer.cpp   1.292.2.1
  M +1 -1      misc/Makefile.am   1.33.2.1
  M +41 -3     misc/helper.cpp   1.58.2.1
  M +2 -0      misc/helper.h   1.18.2.1
  M +50 -0     misc/shared.h   1.2.8.1
  M +4 -0      rendering/bidi.cpp   1.203.2.1
  M +126 -0    rendering/render_block.cpp   1.56.2.1
  M +14 -0     rendering/render_block.h   1.21.2.1
  M +13 -0     rendering/render_box.cpp   1.248.2.1
  M +7 -0      rendering/render_box.h   1.83.2.1
  M +28 -1     rendering/render_br.cpp   1.20.2.1
  M +13 -12    rendering/render_br.h   1.26.2.1
  M +1 -0      rendering/render_canvas.h   1.56.2.1
  M +35 -0     rendering/render_container.cpp   1.56.2.1
  M +7 -1      rendering/render_container.h   1.14.2.1
  M +15 -1     rendering/render_inline.cpp   1.15.2.1
  M +6 -0      rendering/render_inline.h   1.11.2.1
  M +1 -1      rendering/render_layer.cpp   1.46.2.1
  M +120 -0    rendering/render_line.cpp   1.18.2.1
  M +25 -5     rendering/render_line.h   1.7.4.1
  M +235 -0    rendering/render_object.cpp   1.275.2.1
  M +34 -2     rendering/render_object.h   1.200.2.1
  M +47 -0     rendering/render_replaced.cpp   1.181.2.1
  M +5 -12     rendering/render_replaced.h   1.80.2.1
  M +2 -2      rendering/render_table.cpp   1.267.2.1
  M +139 -18   rendering/render_text.cpp   1.258.2.1
  M +20 -18    rendering/render_text.h   1.118.2.1
  M +4 -2      xml/Makefile.am   1.17.6.1
  M +169 -38   xml/dom_docimpl.cpp   1.303.2.1
  M +29 -0     xml/dom_docimpl.h   1.139.2.1
  M +55 -32    xml/dom_elementimpl.cpp   1.202.2.1
  M +6 -2      xml/dom_elementimpl.h   1.118.2.1
  M +187 -13   xml/dom_nodeimpl.cpp   1.244.2.1
  M +43 -15    xml/dom_nodeimpl.h   1.163.2.1
  M +36 -21    xml/dom_textimpl.cpp   1.103.2.1
  M +13 -1     xml/dom_textimpl.h   1.60.4.1



Comment 19 Nicolas Deschildre 2004-12-13 18:41:17 UTC
On Monday 13 December 2004 01:39, Leo Savernik wrote:
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug, or are watching someone who is.
> You are a voter for the bug, or are watching someone who is.
>
> http://bugs.kde.org/show_bug.cgi?id=48302
>
>
>
>
> ------- Additional Comments From l.savernik aon at  2004-12-13 01:39
> ------- CVS commit by savernik:
>
> Merge of WebCore's caret mode, and contenteditable changes.
>
> With this merge, rudimentary editing of html fragments becomes possible.
>
> The changes are not nearly stable or feature-complete. Hence, design mode
> is developed in a branch of its own.
>
> Don't expect contenteditable/design mode to be shipped with KDE 3.4.
>
> The unwary of you may check out the design_mode branch of khtml to get an
> impression about the current state and progress.

Good news!
But i'm afraid i won't be able to test it right now (exams and so on...). I'll 
try to report you my impressions during the holidays

Nicolas

>
> CCMAIL: 48302 bugs kde org
>
>
>   A            editing/.cvsignore   1.1.2.1
>   A            editing/Makefile.am   1.1.2.1
>   A            editing/edit_command.h   1.1.2.1 [LGPL (v2+)]
>   A            editing/edit_command_adapter.cpp   1.1.2.1 [LGPL (v2+)]
>   A            editing/edit_command_adapter.h   1.1.2.1 [LGPL (v2+)]
>   A            editing/editing.cpp   1.1.2.1 [LGPL (v2+)]
>   A            editing/editing_p.h   1.1.2.1 [LGPL (v2+)]
>   A            editing/editor.cpp   1.1.2.1 [LGPL (v2+)]
>   A            editing/editor.h   1.1.2.1 [LGPL (v2+)]
>   A            editing/editor_command.h   1.1.2.1 [LGPL (v2+)]
>   A            editing/htmlediting.cpp   1.1.2.1 [UNKNOWN]
>   A            editing/htmlediting.h   1.1.2.1 [UNKNOWN]
>   A            editing/htmlediting_impl.cpp   1.1.2.1 [UNKNOWN]
>   A            editing/htmlediting_impl.h   1.1.2.1 [UNKNOWN]
>   A            editing/jsediting.cpp   1.1.2.1 [UNKNOWN]
>   A            editing/jsediting.h   1.1.2.1 [UNKNOWN]
>   A            misc/khtml_partaccessor.h   1.1.2.1 [LGPL (v2+)]
>   A            xml/dom_position.cpp   1.1.2.1 [UNKNOWN]
>   A            xml/dom_position.h   1.1.2.1 [UNKNOWN]
>   A            xml/dom_positioniterator.cpp   1.1.2.1 [UNKNOWN]
>   A            xml/dom_positioniterator.h   1.1.2.1 [UNKNOWN]
>   A            xml/dom_selection.cpp   1.1.2.1 [UNKNOWN]
>   A            xml/dom_selection.h   1.1.2.1 [UNKNOWN]
>   M +299 -0    ChangeLog   1.353.2.1
>   M +2 -1      Makefile.am   1.162.2.1
>   M +10 -9     khtml_events.cpp   1.17.8.1
>   M +3 -0      khtml_iface.cc   1.10.6.1
>   M +710 -189  khtml_part.cpp   1.1063.2.1
>   M +120 -7    khtml_part.h   1.270.2.1
>   M +1 -0      khtmlimage.cpp   1.44.2.1
>   M +21 -49    khtmlpart_p.h   1.60.2.1
>   M +149 -65   khtmlview.cpp   1.674.2.1
>   M +12 -5     khtmlview.h   1.215.2.1
>   M +4 -1      css/css_valueimpl.h   1.57.2.1
>   M +48 -0     dom/dom_doc.cpp   1.56.4.1
>   M +12 -0     dom/dom_doc.h   1.44.2.1
>   M +0 -12     dom/dom_element.cpp   1.49.2.1
>   M +17 -0     dom/html_element.cpp   1.25.8.1
>   M +30 -0     dom/html_element.h   1.25.2.1
>   M +31 -0     ecma/kjs_dom.cpp   1.182.2.1
>   M +4 -2      ecma/kjs_dom.h   1.72.2.1
>   M +9 -0      ecma/kjs_html.cpp   1.279.2.1
>   M +2 -1      ecma/kjs_html.h   1.82.2.1
>   M +42 -0     html/html_elementimpl.cpp   1.182.2.1
>   M +4 -0      html/html_elementimpl.h   1.76.2.1
>   M +1 -3      html/html_inlineimpl.cpp   1.137.2.1
>   M +2 -0      html/htmltokenizer.cpp   1.292.2.1
>   M +1 -1      misc/Makefile.am   1.33.2.1
>   M +41 -3     misc/helper.cpp   1.58.2.1
>   M +2 -0      misc/helper.h   1.18.2.1
>   M +50 -0     misc/shared.h   1.2.8.1
>   M +4 -0      rendering/bidi.cpp   1.203.2.1
>   M +126 -0    rendering/render_block.cpp   1.56.2.1
>   M +14 -0     rendering/render_block.h   1.21.2.1
>   M +13 -0     rendering/render_box.cpp   1.248.2.1
>   M +7 -0      rendering/render_box.h   1.83.2.1
>   M +28 -1     rendering/render_br.cpp   1.20.2.1
>   M +13 -12    rendering/render_br.h   1.26.2.1
>   M +1 -0      rendering/render_canvas.h   1.56.2.1
>   M +35 -0     rendering/render_container.cpp   1.56.2.1
>   M +7 -1      rendering/render_container.h   1.14.2.1
>   M +15 -1     rendering/render_inline.cpp   1.15.2.1
>   M +6 -0      rendering/render_inline.h   1.11.2.1
>   M +1 -1      rendering/render_layer.cpp   1.46.2.1
>   M +120 -0    rendering/render_line.cpp   1.18.2.1
>   M +25 -5     rendering/render_line.h   1.7.4.1
>   M +235 -0    rendering/render_object.cpp   1.275.2.1
>   M +34 -2     rendering/render_object.h   1.200.2.1
>   M +47 -0     rendering/render_replaced.cpp   1.181.2.1
>   M +5 -12     rendering/render_replaced.h   1.80.2.1
>   M +2 -2      rendering/render_table.cpp   1.267.2.1
>   M +139 -18   rendering/render_text.cpp   1.258.2.1
>   M +20 -18    rendering/render_text.h   1.118.2.1
>   M +4 -2      xml/Makefile.am   1.17.6.1
>   M +169 -38   xml/dom_docimpl.cpp   1.303.2.1
>   M +29 -0     xml/dom_docimpl.h   1.139.2.1
>   M +55 -32    xml/dom_elementimpl.cpp   1.202.2.1
>   M +6 -2      xml/dom_elementimpl.h   1.118.2.1
>   M +187 -13   xml/dom_nodeimpl.cpp   1.244.2.1
>   M +43 -15    xml/dom_nodeimpl.h   1.163.2.1
>   M +36 -21    xml/dom_textimpl.cpp   1.103.2.1
>   M +13 -1     xml/dom_textimpl.h   1.60.4.1

Comment 20 Jason Keirstead 2005-03-01 18:13:19 UTC
*** Bug 99042 has been marked as a duplicate of this bug. ***
Comment 21 Anders E. Andersen 2006-03-22 14:09:25 UTC
What's the story here? :) No activity for a while.
Comment 22 Leo Savernik 2006-03-22 19:40:51 UTC
Suspended indefinitely.

A merge from Webcore will be done when the infrastructure is in place. Don't even think about expecting it before KDE 4.
Comment 23 Brad Hards 2007-10-13 12:54:37 UTC
Did this get merged for KDE4?
Comment 24 Leo Savernik 2007-10-13 18:50:53 UTC
No. With the imminent availability of QtWebKit, solving this bug is futile.
Comment 25 Germain Garand 2007-10-13 20:02:32 UTC
Well, some people still have better ambitions for KDE than vassal of Apple corp. This bug will remain open.
Comment 26 Leo Savernik 2007-10-13 23:32:13 UTC
Am Samstag, 13. Oktober 2007 schrieb Germain Garand:
> Well, some people still have better ambitions for KDE than vassal of Apple
> corp. This bug will remain open.


Ok. Nice to hear that khtml is scheduled to last.
Comment 27 Anders Jenbo 2007-11-05 14:36:27 UTC
Hi, I work on a WYSIWYG editor called RTEF, it's main goal is to support any browser out there, currently we have IE 5.0+, Opera 9+, Mozilla 1.3+, Firefox 0.6.1+, Netscape 7.1+ and Safari 1.3+. I think Konqueror is realy missing from this list so i just wanted you guys to know that I support you in the effort to enable designMode for Konqueror. I would be glad to provide all the help I can, in form of JS and test versions of RTEF for Konqueror as well as testing builds of Konqueror (mind you I have only used KDE (KUbuntu) for 2 dayes as of this writing).

Hopfully some organisation like WC3 will soon pick up designMode and make it a clan standard as it realy is the missing part of "Web 2.0".

http://rtef.info/

Anders Jenbo
Comment 28 Tommi Tervo 2007-11-16 08:36:46 UTC
*** Bug 152399 has been marked as a duplicate of this bug. ***
Comment 29 Germain Garand 2007-12-21 21:36:34 UTC
I will work on this.
Target is KDE 4.1, thanks to the help and excellent prior work of Leo Savernik.
Comment 30 Anders Jenbo 2008-03-07 22:34:15 UTC
Some notes on best practice in styling html.
Use <b> for bold <i> for italic and <u> for underlined.
Safari made the mistake of applying every thing using <span style=""> leaving the produced code cluttered and impossible to affect using style sheets to follow a pages design.
IE uses <strong> for bold, this is semantical better then <b> in the cases where the selected text should have importance, but the editor probably won't know if the users is just bolding or marking a word for importance.
IE uses <em> for the same reason.
Firefox uses <b> and <i>
Opera uses <b> and <em>
As the scene is already cluttered the decision for what specific tag to use is petty much up to you, but inline styling is a bad idea.
For more specific styling like font size i would again suggest using tags where possible like nested <big> and <small>, for things that doesn't have a good tag answer inline styling would be better then using <font> like IE, generally all layout attribute (not counting style="") should be avoided as they do not provide any added value/functionality over css and are deprecated in newer html/xhtml editions.
Comment 31 George Goldberg 2008-05-06 06:35:34 UTC
*** Bug 117934 has been marked as a duplicate of this bug. ***
Comment 32 Germain Garand 2008-05-19 00:27:10 UTC
SVN commit 809453 by ggarand:

implementation for contentEditable/designMode

based on work by Apple developers and Leo Savernik.
Still needs further work, but should be reasonably stable.

CCBUG: 48302


 M  +12 -0     CMakeLists.txt  
 M  +48 -0     dom/dom_doc.cpp  
 M  +12 -0     dom/dom_doc.h  
 M  +0 -12     dom/dom_element.cpp  
 M  +17 -0     dom/html_element.cpp  
 M  +30 -0     dom/html_element.h  
 M  +31 -0     ecma/kjs_dom.cpp  
 M  +3 -1      ecma/kjs_dom.h  
 M  +9 -0      ecma/kjs_html.cpp  
 M  +2 -1      ecma/kjs_html.h  
 A             editing (directory)  
 A             editing/edit_command.h   [License: LGPL (v2+) (wrong address)]
 A             editing/editing.cpp   [License: LGPL (v2+) (wrong address)]
 A             editing/editing_p.h   [License: LGPL (v2+) (wrong address)]
 A             editing/editor.cpp   [License: LGPL (v2+) (wrong address)]
 A             editing/editor.h   [License: LGPL (v2+) (wrong address)]
 A             editing/editor_command.h   [License: LGPL (v2+) (wrong address)]
 A             editing/htmlediting.cpp   [License: BSD]
 A             editing/htmlediting.h   [License: BSD]
 A             editing/htmlediting_impl.cpp   [License: BSD]
 A             editing/htmlediting_impl.h   [License: BSD]
 A             editing/jsediting.cpp   [License: BSD]
 A             editing/jsediting.h   [License: BSD]
 M  +42 -0     html/html_elementimpl.cpp  
 M  +4 -0      html/html_elementimpl.h  
 M  +1 -3      html/html_inlineimpl.cpp  
 M  +0 -11     khtml_caret_p.h  
 M  +10 -9     khtml_events.cpp  
 M  +545 -562  khtml_part.cpp  
 M  +100 -4    khtml_part.h  
 M  +3 -27     khtmlpart_p.h  
 M  +103 -978  khtmlview.cpp  
 M  +3 -250    khtmlview.h  
 M  +37 -3     misc/helper.cpp  
 M  +2 -0      misc/helper.h  
 A             misc/khtml_partaccessor.h   [License: LGPL (v2+) (wrong address)]
 M  +1 -1      misc/loader.cpp  
 M  +126 -0    rendering/render_block.cpp  
 M  +12 -1     rendering/render_block.h  
 M  +28 -1     rendering/render_br.cpp  
 M  +13 -12    rendering/render_br.h  
 M  +1 -0      rendering/render_canvas.h  
 M  +30 -0     rendering/render_container.cpp  
 M  +6 -0      rendering/render_container.h  
 M  +15 -2     rendering/render_inline.cpp  
 M  +6 -0      rendering/render_inline.h  
 M  +1 -1      rendering/render_layer.cpp  
 M  +113 -0    rendering/render_line.cpp  
 M  +19 -5     rendering/render_line.h  
 M  +200 -0    rendering/render_object.cpp  
 M  +23 -2     rendering/render_object.h  
 M  +47 -0     rendering/render_replaced.cpp  
 M  +9 -12     rendering/render_replaced.h  
 M  +1 -1      rendering/render_table.cpp  
 M  +134 -18   rendering/render_text.cpp  
 M  +20 -18    rendering/render_text.h  
 M  +66 -0     xml/dom_docimpl.cpp  
 M  +19 -0     xml/dom_docimpl.h  
 M  +48 -32    xml/dom_elementimpl.cpp  
 M  +5 -3      xml/dom_elementimpl.h  
 M  +170 -13   xml/dom_nodeimpl.cpp  
 M  +42 -15    xml/dom_nodeimpl.h  
 A             xml/dom_position.cpp   [License: BSD]
 A             xml/dom_position.h   [License: BSD]
 A             xml/dom_positioniterator.cpp   [License: BSD]
 A             xml/dom_positioniterator.h   [License: BSD]
 A             xml/dom_selection.cpp   [License: BSD]
 A             xml/dom_selection.h   [License: BSD]
 M  +36 -19    xml/dom_textimpl.cpp  
 M  +13 -1     xml/dom_textimpl.h  


WebSVN link: http://websvn.kde.org/?view=rev&revision=809453
Comment 33 FiNeX 2008-05-19 13:23:41 UTC
@Germain Garand: will be supported editors like fckeditor or tinyMCE?
Comment 34 Kae Verens 2008-05-19 13:50:03 UTC
@FiNeX

as far as I know, this is the only thing that's stopping FCKeditor and TinyMCE from working.
Comment 35 FiNeX 2008-05-19 13:54:33 UTC
@Kae: so this latest patch could be useful for make them work?
Comment 36 A. Spehr 2008-05-19 16:40:43 UTC
Germain: Does that commit mean this wish is implemented?
(And yay to you and Leo on the commit, btw!)
Comment 37 Germain Garand 2008-05-19 17:38:21 UTC
re:  FiNEX, Alex. It's on its way but there is still a lot of work to do.
The caret position is often bogus, command compression is disabled because of refcounting issues, there are many missing commands. Undo manager isn't implemented at all. I must still make designMode enabling match what the HTML5 spec says.

I'll CC here on further progress anwyay.
Comment 38 Leo Savernik 2008-05-19 18:27:50 UTC
Am Montag, 19. Mai 2008 schrieb Germain Garand:
> implementation for contentEditable/designMode


Yay! A big thank you for finishing the work I started in Summer 2003 and 
meanwhile abandoned due to lack of time. And a big thank you for resurrecting 
the rotten pile of designmode-branch, fiddling with it and porting it to KDE 
4.

:-)
Comment 39 FiNeX 2008-06-01 19:21:22 UTC
*** Bug 134915 has been marked as a duplicate of this bug. ***
Comment 40 FiNeX 2008-06-27 16:57:09 UTC
*** Bug 141523 has been marked as a duplicate of this bug. ***
Comment 41 FiNeX 2008-06-27 16:58:17 UTC
*** Bug 95923 has been marked as a duplicate of this bug. ***
Comment 42 Zayed Al-Saidi 2008-08-31 09:47:26 UTC
What is the status of wish ? Will it be ready for kde 4.2?
Comment 43 FiNeX 2008-09-25 13:56:55 UTC
*** Bug 68319 has been marked as a duplicate of this bug. ***
Comment 44 R Bauer 2008-09-25 14:18:39 UTC
Me wants to see fckeditor working too

http://www.fckeditor.net/
Comment 45 Viacheslav Tokarev 2008-12-08 21:08:35 UTC
SVN commit 894515 by vtokarev:

Fix the caret off-by-one bug: make sure we update layout before setting
new caret position
CCBUG:48302
CCBUG:177245

 M  +10 -0     editor.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=894515
Comment 46 FiNeX 2009-06-16 14:17:15 UTC
*** Bug 196427 has been marked as a duplicate of this bug. ***