Custom Query

It is sometimes very confortible to have a prepared config file where You could see all the available configuration (commented out) and its documentation without having to go online and search what configuration parts are worth to be added to some particular project (it takes less time to go through config text file).

I have made such sample configuration file and would like to suggest to add it to the project. It is based on the official documentation and at the moment - up to date. In the first usage examples I have placed default values instead of writting them seperately.

I've got a problem with unordered / numbered lists with IE8 on WindowsXP.

• Create an unordered list with some items.
• Now try to get one item to the upper line with the "delete"-key.
• This will not work.
• If you try the "backspace"-key on the line that should be added to the item above you got an inconsistent list, because the </li>-Tag of the upper line will not disappear.

This error is not in Firefox3 (WinXP), but IE8 (Windows7)

This is also the case in ​http://ckeditor.com/demo/

We are mainly focused on cleaning up the content while pasting, but there is still a lot of content in various systems that was created long time ago that may contain broken / invalid HTML.

Suppose we have the following HTML source at the beginning:

<p><font face=""><font face=""><font face="">fooo</font></font></font></p>

The <font> tag is totally useless there and theoretically could be simply removed by CKEditor from the HTML source.

CKEditor has some problem with delete cells in tables. After delete any cell, table layout is incorrect. In my opinion we should remove option 'delete cells' (many editors working like that example Excel - only allow to remove row or column, no single cell) or after this action do colspan or rowspan to keep table layout stable.

There might be a situation, when one wants to use a custom tag, for example to process it on the server side later.

There is a problem with handling custom tags when inserting the content into the editor.

When checking the _samples/api.html sample and trying to paste the following content into the blank wysiwyg area with the "Insert HTML" button:

<dynamic>http://www.google.com</dynamic>

the result is as follows (tested in rev 5872):

• IE 6: dynamic tag is lost: <p>http://www.google.com</p>
• IE 7: dynamic tag is lost: <p>http://www.google.com</p>
• IE 8: dynamic tag is lost: <p>http://www.google.com</p> (the result in FCKEditor 2.6.6 is different: <p><dynamic></dynamic>http://www.google.com</p>)
• FF 3.6.9: dynamic tag is lost: <p>http://www.google.com</p>
• Safari 5.0.2: dynamic tag is pasted correctly <p><dynamic>http://www.google.com</dynamic></p>

When switching from the source mode to wysiwyg mode and back with the following HTML:

<p><dynamic>http://www.google.com</dynamic></p>

the result is correct in all cases:

• IE6: <p><dynamic>http://www.google.com</dynamic></p>
• IE7: <p><dynamic>http://www.google.com</dynamic></p>
• IE8: <p><dynamic>http://www.google.com</dynamic></p>
• FF 3.6.9: <p><dynamic>http://www.google.com</dynamic></p>
• Safari 5.0.2: <p><dynamic>http://www.google.com</dynamic></p>

1. use IE9 (also applies in IE 7/8)

2. Go to ckeditor.com/demo

3. click 'New Page'

4. click outside of the wysiwyg text editor (so as to lose focus)

5. click inside of the wysiwyg text editor (so as to regain focus)

[Expected] clicking anywhere within the white editing area will focus the editor.

[Actual] The clickfield to accomplish the expected result is very small - only the area shown in the attached image. Clicking anywhere outside of that area will focus the editor's containing element and will not permit editing. The available clickfield is dependant on the amount of content within the editor, however it's always possible to click on a 'dead zone' and lose focus. (E.g., go to ckeditor.com/demo and click to the left of the word "tells" below the picture of Little Red Riding Hood.)

Other details which may or may not be useful:

We had implemented a workaround for this which relies on IE7's ​moveToPoint and was able to fix the vast majority of IE's quirks that cause this problem. Unfortunately, IE9's implementation of moveToPoint differs, and so our workaround is gone. A slight improvement is to detect the failure case and simply focus the editor (which at least makes creating a new article in IE9 feasible), however there are a lot of edge cases which that fails to cover (dragging a selection in and out of the dead zone, etc.)

Run the attached code example. Click to put the cursor at beginning of first line - event fired. Now drag select within the same line - event NOT fired. Now drag select within the second line - event fired.

The Link dialog window lets the user choose an anchor from a drop-down list by its ID. However, the ID for an anchor can only be added while editing the source and not via the UI.

Providing an option to add an ID to the Anchor dialog window would make the system more consistent.

'showblocks' outlook should have the similar mirroring effects with indentation commands.

Browsers that don't support tag editing still support ckeditor's source mode, which is better than nothing, and provides a more gradual operational decline.

My suggested patch creates a env.isTextCompatible var, and if env.isCompatible is false but env.isTextCompatible is true, ckeditor defaults to a text entry mode with limited, but still existent functionality.

Currently, when enterMode is BR, justifying text results in a paragrpah, and adding direction results in a DIV. In both cases paragraph should be used.

The 'align' attribute used on table element actually makes the table right floated.

1. Load the following content:

   <p>
   	text line before table.
   </p>
   <table>
   	<tr>
   		<td>cell</td>
   		<td>cell</td>
   	</tr>
   	<tr>
   		<td>cell</td>
   		<td>cell</td>
   	</tr>
   </table>
   <p dir="rtl">
   	text line after table.
   </p>
   

2. Make selection in table, open properties dialog and select right alignment;

• Actual Result: table is floated at the right side (overlap the layout box of last line);
• Expected Result: table occupied line height in layout flow.

In the first colors dialog that appears straight after pressing "Text Color" or "Background Color" button, the up/down keyboard arrow keys doesn't work as expected - pressing the down key moves to the next color on the right side instead to the next color in the line below.

It looks like it never worked properly.

From time to time we receive incompleteness structure when pasting from MS-Word (#6484,#6608) because by default "pasteFromWordRemoveFontStyles" is disabled, which strips inline styles delivered by the application.

While the original intention was to keep the output clean, it nows seems more reasonable to accept those styles than loose them.

Hi, I'm mike from the OTRS project. We use CKEditor in our open source software, and generally our users are really happy with it.

One thing that we found out recently is that if you're on Windows, with Firefox 3,6, you can paste an image in the editor by clicking Ctrl+v on the keyboard. If you do this on Win7 or WinVista, then the result is a broken image icon diplayed in the editor. If you look at the source there's an <img> tag which points at the file in the users temp dir on the local hard drive.

However, if you use Firefox 3.x on WinXP apparently the image IS displayed properly inside the editor so it LOOKS like the image is there, only obviously the path is still local. This is nastier because the user THINKS it worked, and submits the entry. Only for anyone using a different PC the file is not in this location, so they don't see the image.

Inserting an image using the image button in the CKEditor toolbar works just fine.

1.) CKeditor should stop making Ctrl+v with image data on the clipboard insert broken <img> tags?

2.) since apparently the link to a file is available, it would be great if this same action could open the image dialog with the link to the local file pre-populated.

We even have users who reported that it works for them already in the way described in 2) just I could not find the browser/OS combination to reproduce that.

I guess it's known but I couldn't find a related report: there's no image resize in Opera, Safari, Chrome. I guess browser support and/or a plugin is needed?

Test:

• insert <span contenteditable="false">Some<a href="xxx">Link</a>Text</span>
• IE: drag-n-drop of wrapper rectangle works; drag-n-drop selection duplicates content with <a>...</a> stripped (text mode-like)
• Firefox: you can drag just the <a> element; a copy is made with all enclosing tags kept (html duplicate)
• Chrome: worst case: the <a> is duplicated with no enclosing tags

IMO, when drag-and-dropping non-editable blocks, the following should happen:

• the block be moved, not copied, in full
• if such reason exists to duplicate content, it should either be a full copy of the non-editable tag or IE-style sanitized text duplication of fragments. Since the whole idea of having noneditable sections is to allow developer fixed-format fragments to be inserted, any different behavior will break functionality.

Unlike "insertHtml", "insertElement" invoking that happens on a text selection in structure like table and list either leaves a malformed DOM or even an error.

The following tickets are associated:

It seems as the when selecting text in the editor and pasting over that, the paste keeps the previous styling in some strange way.

To reproduce:

Select the text below and paste into a empty editor:

Start text:
text that is styled bold text that is unstyled
End text

After the text has been pasted. Do ctrl+a to select all and then ctrl+v to paste the same text again.

All text is now bold. Repeating this introduces a new nested bold tag each time.

1. In my opinion application should clear styling when select all (ctrl+a) is issued.
   
2. And not insert a strong tag when there already is one.
   
3. In word you get the styling of what you paste not the styling of what you paste plus the styling of where you paste.
   

I understand that this is a area where different people would argue that different behavior is right. My opinion is that MS word behavior makes sense to me.

Currently there are many translations that haven't been updated for a very long time. They take extra space for the people that don't mess too much with the provided files and with so many missing strings they are hardly useful for the end user.

There are also some files like the Canadian French that it's quite less updated than the regular French file, so I wonder if the users prefer to look at some words better translated to their country locale or see more words in French instead of English. (besides the fact that many times both translations could be used for all the French countries as the difference could be really just a point of view of the translator at that moment but it's possible to have a single file).

I will remove any obsolete translation in the next release of Write Area with CKEditor, removing the files with over 200 missing entries saved 90Kb, so I think that I might go ahead and even remove the ones that are over 100 missing entries.

Of course, a call to the translators should be done in order to try to find people that can take some time to update its locale if he doesn't want it removed.

Steps to reproduce the defect:

1. Open the Ajax sample.
2. Click on Align Right (or Align Centre).
3. Select Heading 1 from the paragraph format drop down list.
4. Type some text & press Enter.

Expected: The cursor stays Right Aligned (or Centre Aligned).

Actual: The cursor becomes Left Aligned.

In a few dialog we have fixed width for content, so the dialog is resizable but the content size is never changed.
We need to make the content resizable (or cancel the resizing option of them).

• Spell checker (covered by #6829).
• Paste.
• Special characters.
• Select color.

Steps to Reproduce:

1. Open the Ajax sample.
2. Insert a table.
3. Click into the first cell & click RTL icon in the toolbar.
4. Keep the cursor in the first cell & type 3 paragraphs of text.
5. Select all 3 paragraphs & click on the Bulleted List icon.
6. See the Bulleted List is in the RTL language direction.
7. Copy the Bulleted List and paste it in the editor outside of the table.

Expected: The Bulleted List that was pasted outside of the table has RTL language direction.

Actual: The Bulleted List that was pasted outside of the table has LTR language direction.

IMO forms creation should be much like DIV creation, wrapping the selection rather than removing it.

Style combo item is not presented under the preview style of the each style definition (same with format combo), sometimes this isn't an option at all (seen on user request #6379), the editor should allow an alternative presentation to be provided in the following format:

	{
		name : 'Colored: White',
		element : 'span',
		styles : { 'color' : 'White' },
		displayHtml: '<span style="background-color:#000;color:#fff;">Colored:White</span>'
	}

To reproduce the defect:

Scenario 1:

1. Open CK Editor and insert a Table.

2. Keep cursor inside a Table Cell and click on Block Quote icon.

Expected Result:

Block Quote is applied to Table Cell.

Actual Result:

Block Quote is applied to whole Table.

Scenario 2:

1. Open CK Editor and insert a Table.

2. Type some text inside a Table Cell, select the paragraph and click on Block Quote icon.

Expected Result:

Block Quote is applied to the selected paragraph inside Table Cell.

Actual Result:

Block Quote is applied to whole Table.

Use the following styles:

	{ name : 'Red Title'		, element : 'h3', styles : { 'color' : 'Red' } },
	{ name : 'Red title with blue background'		, element : 'h3', styles : { 'color' : 'Red', 'background-color' : 'Blue' } }

And the following content (place the caret somewhere inside the <h3>:

<h3 style="color: red; background-color: blue;">
	This is some <strong>sample text</strong>. You are using <a href="http://ckeditor.com/">CKEditor</a>.</h3>

Open the styles combo. Both "Red title" and "Red title with blue background" are marked as focused, while only "red title" is presented in the combo label. IMO the label should read "Red title with blue background".

DUP with a better description: #7220.

Test/Use Case

• clear content and insert an default empty table 3x2.

In MS Word, user is allowed to select whole table by clicking [+] in left upper corner, then it is possible to set unified format to all table cells and resizing. CKEditor also allows selection of whole table for resizing.

• select whole table (click on the border), so the resize options are visible

Instead of resize try to change formating

• select blue from styles combo box

Result in IE6 - part of cells are deleted

<h3 style="color: blue">
	&nbsp;</h3>
<h3 style="color: blue">
	&nbsp;</h3>
<h3 style="color: blue">
	&nbsp;</h3>
<h3 style="color: blue">
	&nbsp;</h3>
<table border="1" cellpadding="1" cellspacing="1" style="width: 500px">
  <tbody>
	<tr>
 	<td>
		&nbsp;</td>
	</tr>
	<tr>
	</tr>
	<tr>
	<td>
		&nbsp;</td>
	</tr>
	</tbody>
</table>
<p>
	&nbsp;</p>

In CKEditor v3.5 it was not possible to select style when table resize icons were visible

Should it be possible to set formating this way? Or when resizing table, setting format should be disabled?

In Opera, formating is set outside of selected table, but without changes inside.

<h2>
	&nbsp;</h2>
<table border="1" cellpadding="1" cellspacing="1" style="width: 500px">
	<tbody>
...

In Firefox, only first cell got formating

as in MsWord, it looks nice to have line spacing option as in button click: -Space Sizes List -add/remove spacing after paragraph -add/remove space before paragraph

I Think this will completethe editor to be as perfect as using MSWORD.

At the very least, in that function the

	var styles = CKEDITOR.style.getStyleText( def );

isn't used, but the final part to remove the style has remained that way since it was created in [5847] that changed also the applyObjectStyle but was reverted in [5978]

So a little clean up is needed there, deciding if it must use getStyleText or def.Styles (but using a local variable), and correcting the comments.

Run attached example. Copy "Sans" from first line. Paste as plain text at end of second line. On IE, the copied font is maintained. On FF, the text is pasted with default font.

Is this a browser difference?

To reproduce the defect:

In the Table Properties enter invalid values(-20 or 35ex) for width and press OK button.

Expected Result: An error dialog comes up with a waring message width must be a positive number greater than zero and valid CSS units are px em % .

Actual Result: An error dialog comes up with a waring message Specified value must be a valid CSS length unit

same issue when we enter invalid value for Height

This is not satisfying the criteria for A11y Checkpoint 3.3

Split from #8226

I think that many new users don't realize that they have errors in the console (after all IE is the only browser that currently shows clearly when a page has a js error). We must remember that many people aren't javascript developers, that's why they use things like the asp.net or Java adapters, they just know how to work at the server side and when they try to copy some javascript code as shown in some examples and doesn't work they don't understand what's the problem.

So I strongly suggest to change throw '[CKEDITOR.editor] The instance "' + previous.name + '" already exists.'; to alert('[CKEDITOR.editor] The instance "' + previous.name + '" already exists.'); }

Labels for all required fields on our dialogs should have an astrisk(*) and instructions for identifying required fields should be clearly labeled at the beginning of the form.

This is a failure of Accessibility Checkpoint 1.3.1

This is clearly documented in Examples of Success Criterion for 1.3.1

See links here.. ​http://www.w3.org/TR/2012/NOTE-UNDERSTANDING-WCAG20-20120103/content-structure-separation-programmatic.html

​http://www.w3.org/TR/WCAG20-TECHS/H44.html

styles.js looks to me like a leftover from FCKeditor for which we did not find a better place.

What's exactly the problem with this file?

It contains sample data used exclusively by two optional plugins (if I'm correct): stylescombo and div. In fact the default styles.js does not contain even a single sample for the div dialog, so it's just a sample file for the "Styles" combo.

If styles.js is not an essential part of core, it should be rather located in the plugin folder.

Proposed solution:

1. Move styles.js into the folder of stylescombo plugin.
2. The default value for stylesSet should be empty. Eventually it could be overwritten by the stylescombo plugin, because only then styles.js will be available. There is a hardcoded path to CKEDITOR.getUrl( 'styles.js' ) somewhere in core/styles.js.
3. To make user's life easier, we can eventually move 'styles.js' into the root folder (using a special directive in the manifest file) of CKEditor, but only if the "stylescombo" plugin is included in the release.

Point (3) leads to some additional problems:

4. If we go ahead with (3) why the templates plugin should be different? To specify the teplate one have to go into the templates' plugin folder.
5. If we go ahead with (3) we will have different paths to styles.js in development, source and release modes.

Last word regarding core...

Comments in core/styles.js mention the "Styles" combo. It's quite unclear where does it come from if we treat plugins as separate things. I believe comments must be corrected as well to clearly specify which plugin provides it and how it is used.

1. Load the replacebyclass in IE;
2. Check the toolbar status without focusing the document;

• Actual: the toolbar is not properly given the initial states as in other browsers.
• Expected: the toolbar should reflects the selection as if it's anchored at the start of document, this works for Firefox and Webkit.

I'm a little bit concerned about the expected behavior of "insert column before" for the following case:

+-----+------+
| 1.1 | 1.2^ |
+-----+------+
| 2.1 |
+-----+

How it works now:

+-----+--------+------+
| 1.1 |   | 1.2^ |
+-----+--------+------+
| 2.1 |
+-----+

How it should look like in my opition:

+-----+--------+------+
| 1.1 |   | 1.2^ |
+-----+--------+------+
| 2.1 |   |
+-----+--------+

Most likely this is not an issue but it brings some confusion. The origin of this issue is in #9609.

Question based on ​http://dev.ckeditor.com/ticket/9622#comment:4

Solution (or lack of it) should be discussed first.

We do several inline elements fixing that are found orphan inside body. This was true for <br> as well, until we reverted a fix that was causing #9167.

Because of that, I've commented out a test made for that case form dt/core/htmlparser/fragment.html, test name "test_parser_13".

It is still unclear for me the cases for this fix, but considering that we were used to do so, we should keep doing it.

I'm just unsure if this is necessary.

1. Resize browser window so it's lower than 300px.
2. Open replacebyclass sample.
3. Scroll down.
4. Open image dialog.
5. Try to move it by dragging header.
6. It will stick to upper viewport border. It's impossible to move it lower.

Extracted from #8888.

There is room the enhance the context checking we do for several toolbar buttons. While the current approach is correct, it can be optimized to better fit user's intentions, helping on the UI usability.

One good example for that is related to object selections. There is no much sense on having inline styles, like bold, enabled when an image is selected.

Let's open a discussion and analise all possible cases first.

Why CKEditor fails when I try to call some methods one after another?

editor.setData( someData );
// somewhere later...
editor.destroy();

The answer, unfortunately, isn't simple. Otherwise we'd have this fixed a long time ago. This is a mix of history, backwards compatibility, architectural limitations and lack of good solutions.

First thing to notice is that this is not only editor.setData's problem, because other editor's methods could malfunction too. Editor.getData, editor.destroy, editor.setReadOnly, etc. are not going to work if editor is not in the ready state. Furthermore, this problem concerns some other classes as well - e.g. CKEDITOR.editable.

Second thing to notice is that this problem occurs not only when editor isn't loaded yet, but also when switching between states and setting data (both operations can be asynchronous). This introduces more variables to the equation and could even make the state checks pretty ugly. Fortunately, we introduced editor.status and editable.status (although, we did this pretty recently), so currently this wouldn't be that bad.

Another architectural aspect that would have to be taken into consideration is how the code is decoupled. For instance, the editor.setData method only fires an event. If we started checking the editable's state inside this method we would create a tight relations and could break some existing implementations.

Backwards compatibility is important for one more reason - we can make backward incompatible changes, but we must do them in a smart way. For instance, once it's done it should be final - we can't ship some other solution in the next major release if this one turns out to be unsatisfactory. This rises the stake pretty high.

The last thing, and actually the most unfortunate, is that throwing errors is not that good solution. It may tell you that you're doing something wrong, but it won't tell you when you can do it.

try {
	editor.setData( ... );
} catch ( err ) {
	if ( err instanceof CKEDITOR.editorNotReadyError ) {
		// apparently, it wasn't the right moment
		// ... and what now? Ok, let's wait for some imaginary "ready" event
		// (which doesn't exist right now):
		editor.once( 'ready', function() {
			editor.setData( ... );
			// ... actually, this could throw again if some other editor#ready
			// listener called setData too and haven't cancel the event.
		} );
	} else {
		throw err;
	}
}

Isn't it ugly? I think it's a terrible developer experience. A more useful approach would to be cache method calls and execute them when the editor reaches the correct state. But this would mean that for instance editor.destroy, which is currently a synchronous method, would become an asynchronous one because it can't be executed while editor is not ready. Moreover, to make all this possible to implement we would need to do serious changes not only in the API, but in the editor internals as well. Even the highly unsatisfactory solution with throwing errors requires significant effort to and may lead to ugly compatibility issues.

To sum up. I don't want say that fixing this in CKEditor 4.x is impossible, but for now we didn't have enough resources and well... courage, to attempt that. I would also risk a statement that it's late in CKEditor 4.x for such changes. But most importantly, we are aware of these problems and will definitely ​design CKEditor 5's API differently.

I think we could style differently Advanced Toolbar Configurator on wider screens. Imho it looks a bit weird now on such screens.

Some of the big webmail providers (e.g. Google, Yahoo) have Ajax spell checking with in-line marks showing typos, and a drop down menu of suggestings.

Any possibilities to integrate such for FCKeditor would be a home run!

When using the Opera browser (V9.52 on Windows XP), if I change the view settings to 'Fit to Width' then the edit area of the FCKEditor disappears. The buttons remain however. This happens within my instance of the editor and also on your demonstration page using V2.6.3 of your editor.

Perhaps it's better to implement the 'toString' method on some core objects to help the debugger(e.g. Firebug) having a text presentation for them, which is friendly for debugging.

When we insert a table with 999x99 cells, Firefox get slow and editing is no more possible.

This test is not something users often do, but one of my clients did this test...

Perhaps a limit should be fixed ?

What's reason to use <a> element with javascript: pseudo hrefs?

I think we should use <button>'s for buttons. Why not? Or at least <span>'s. Same with context menus.