| Summary: | khtml support for designMode and contenteditable=true | ||
|---|---|---|---|
| Product: | [Applications] konqueror | Reporter: | Andreas Hochsteger <andreas.hochsteger> |
| Component: | khtml | Assignee: | Konqueror Developers <konq-bugs> |
| Status: | RESOLVED UNMAINTAINED | ||
| Severity: | wishlist | CC: | andrew.dorrell, bartml, cberzan, cedric, finex, fuck, germain, geroxp, ilya.hegai, ingmars, kae, landrews, ndeschildre, pablopedroescobar, pivo, r.bauer, r.pollesch, rdm, schroeder, vedran.vucic, zayed.alsaidi |
| Priority: | NOR | ||
| Version: | 4.0 | ||
| Target Milestone: | --- | ||
| Platform: | openSUSE | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: |
proposed WebCore merges and some utilities
proposed big WebCore merges and some utilities very very very very initial caret navigation quite complete caret navigation |
||
|
Description
Andreas Hochsteger
2002-09-26 09:32:42 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). 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? 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! 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). 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
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! 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). Now I'm really working on it. Taking. 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.
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. Created attachment 2191 [details]
very very very very initial caret navigation
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. 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
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!
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. 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. 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
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 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 *** Bug 99042 has been marked as a duplicate of this bug. *** What's the story here? :) No activity for a while. 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. Did this get merged for KDE4? No. With the imminent availability of QtWebKit, solving this bug is futile. Well, some people still have better ambitions for KDE than vassal of Apple corp. This bug will remain open. 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.
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 *** Bug 152399 has been marked as a duplicate of this bug. *** I will work on this. Target is KDE 4.1, thanks to the help and excellent prior work of Leo Savernik. 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. *** Bug 117934 has been marked as a duplicate of this bug. *** 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 @Germain Garand: will be supported editors like fckeditor or tinyMCE? @FiNeX as far as I know, this is the only thing that's stopping FCKeditor and TinyMCE from working. @Kae: so this latest patch could be useful for make them work? Germain: Does that commit mean this wish is implemented? (And yay to you and Leo on the commit, btw!) 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. 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.
:-)
*** Bug 134915 has been marked as a duplicate of this bug. *** *** Bug 141523 has been marked as a duplicate of this bug. *** *** Bug 95923 has been marked as a duplicate of this bug. *** What is the status of wish ? Will it be ready for kde 4.2? *** Bug 68319 has been marked as a duplicate of this bug. *** Me wants to see fckeditor working too http://www.fckeditor.net/ 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 *** Bug 196427 has been marked as a duplicate of this bug. *** Dear user, KHTML (and KJS) was a long time more or less unmaintained and got removed in KF6. Please migrate to use a QWebEngine based HTML component. We will do no further fixes or improvements to the KF5 branches of these components beside important security fixes. For security issues, please see: https://kde.org/info/security/ Sorry that we did not fix this issue during the life-time of KHTML. Greetings Christoph Cullmann |