Opened 12 years ago

Closed 12 years ago

#3584 closed Bug (wontfix)

Theme is too fragile

Reported by: Alfonso Martínez de Lizarrondo Owned by:
Priority: Normal Milestone:
Component: General Version: SVN (CKEditor) - OLD
Keywords: Confirmed CantFix Doc Cc:


Take a look at #3579.

Due to a simple css rule that includes an ID the toolbar becomes broken. In the real world people uses multiple classes and ID in the css rules, so the styles won't get applied correctly.

Change History (5)

comment:1 Changed 12 years ago by Frederico Caldeira Knabben

Keywords: Pending added

This happened only because you have changed the structure of the sample.html file, which is in fact a template for the "development only" samples.

Do you have a tc page to test it? I should not based on the trunk samples but it may come from the nightly.

comment:2 Changed 12 years ago by Alfonso Martínez de Lizarrondo

I don't think that it's too complex to trigger the problem:

<!DOCTYPE html>
	<title>Sample - CKEditor</title>
	<meta content="text/html; charset=utf-8" http-equiv="content-type"/>
	<script type="text/javascript" src="../ckeditor.js"></script>
	<style type="text/css">
		.mainBody div { border:2px solid red;}
	<div class="mainBody">
				<textarea cols="80" id="editor1" name="editor1" rows="10"></textarea>
				<script type="text/javascript">
					CKEDITOR.replace( 'editor1' );

Just imagine all the possible rules that people might want to apply to their pages by default and then trying to make the editor avoid them might not be an easy task.

comment:3 Changed 12 years ago by Frederico Caldeira Knabben

Keywords: Confirmed added; Pending removed

You're right, and your TC shows the problem precisely.

The only totally safe solution is what we have with V2, iframes to isolate the editor. But here we have a drastic performance payload, and this is one of the benefits on the V3 solution.

We're using a "reset" mechanism, to minimize CSS conflict. But, it looks like it's impossible to have a perfect solution with it, because it depends a lot on CSS rules precedence, and the above TC shows one of these cases.

The only thing that comes to my mind, is providing "information". We should explain the workarounds for such situations. For example, to fix the above TC, it should be enough to add the following rule to the page:

.cke_editor div
	border: 0;

In this way we compensate the previous generic rule.

Do you have further ideas on this? Is it a "CantFix"?

comment:4 Changed 12 years ago by Alfonso Martínez de Lizarrondo

I agree, the "perfect" solution is an iframe, but that has a payload, and most important, now it's quite late.

The problem is that the css rules might be quite complex, and not all the people will be able to find out the exact rules that he needs to add, but at the very least it should be documented.

If I had used <div id="mainBody"> then your suggestion wouldn't work, it needs a rule with higher precedence, so the advice should be #mainBody .cke_editor div

In general: find out the rule that has the highest priority on the editor elements and add the selector .cke_editor somewhere there.

comment:5 Changed 12 years ago by Frederico Caldeira Knabben

Keywords: CantFix Doc? added
Resolution: wontfix
Status: newclosed

Marking as CantFix for now. We need to create documentation for this at some point.

Note: See TracTickets for help on using tickets.
© 2003 – 2021 CKSource – Frederico Knabben. All rights reserved. | Terms of use | Privacy policy