Opened 15 years ago
Closed 15 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: |
Description
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 15 years ago by
| Keywords: | Pending added |
|---|
comment:2 Changed 15 years ago by
I don't think that it's too complex to trigger the problem:
<!DOCTYPE html>
<html>
<head>
<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;}
</style>
</head>
<body>
<div class="mainBody">
<p>
<textarea cols="80" id="editor1" name="editor1" rows="10"></textarea>
<script type="text/javascript">
CKEDITOR.replace( 'editor1' );
</script>
</p>
</div>
</body>
</html>
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 15 years ago by
| 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 15 years ago by
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 15 years ago by
| Keywords: | CantFix Doc? added |
|---|---|
| Resolution: | → wontfix |
| Status: | new → closed |
Marking as CantFix for now. We need to create documentation for this at some point.
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.