Opened 12 years ago

Closed 12 years ago

Last modified 9 years ago

#8790 closed Bug (expired)

webpage css overrides ckeditor 3 style

Reported by: mackiecc Owned by:
Priority: Normal Milestone:
Component: General Version: 3.6.2
Keywords: Cc: chris@…

Description

Hello, my webpages css overrides the style of the ckeditor field. That makes my editor window not only look broken, but also impairs the function seriously (styles from the ckeditor toolbar are applied to wrong locations..). I believe that this problem exists since the editor is directly embedded and not through an iframe (which is generally is good idea).

If I delete my websites main.css everything is working fine. But that's no serious option. The problem was recognized elsewhere, but so far there is no true workaround.

I'm using CKeditor Version 3.6.2. with Firefox/Chromium.

Do you know any workaround? Any help is greatly appreciated! And anyway thanks for providing this great tool.

See also:

http://stackoverflow.com/questions/3864890/webpage-css-overrides-ckeditor-3-style http://stackoverflow.com/questions/5666104/ckeditor-3-table-style-gets-overwritten http://dev.ckeditor.com/ticket/3584

Change History (8)

comment:1 Changed 12 years ago by mackiecc

I did some more research and found a workaround by changing my webpage css:

For Chromium by adding 'cke' rule:

*[class^='cke']  {
     margin: auto !important;
     border: none  !important;
}

For Firefox by uncommenting 'display: table' and adding 'cke' rule:

/* div {
     display: table;
} */
*[class^='cke']  {
     margin: auto !important;
     border: none  !important;
}

There must be some other solution, a texteditor shouldn't be screwed by the webpage css..

comment:2 Changed 12 years ago by Jakub Ś

Keywords: css iframe removed
Status: newpending

For each skin we have a reset file, where we try to fix some things: http://dev.ckeditor.com/browser/CKEditor/trunk/_source/skins/kama/reset.css ; but this will never catch all cases. So, if one wants to break the editor UI, there is little we can do.

Sure that we could add !important rules for every class or we could use rules like margin:0; in every possible scenario or we could list all classes and then add them margin:0; but this still wouldn't probably protect us from all the cases.


Could you tell me what styles have you used to break the editor? Could you post those rules? Something like this perhaps?

* {
	margin: 10px !important;
	border: 5px solid black;
}

Without knowing the source of the problem I won't be able to find out possible solution for it.

comment:3 Changed 12 years ago by Jakub Ś

Resolution: expired
Status: pendingclosed

comment:4 Changed 9 years ago by Chris Graham

Cc: chris@… added

How about we have a JavaScript solution to this.

For the DOM node which CKEditor resides in, there will be a maximum-specificity selector we could derive for it, by analysis of the DOM tree.

For example...

body.website#main_div>div.inner_div[role="article"](...)

Something huge that we programatically work out.

We then dynamically inject a full set of CSS reset rules against that selector, essentially create a very high-precedence reset for the context CKEditor runs in.

And finally, we dynamically rewrite all the CKEditor CSS, prefixing it with our maximal selector, which would now have an even higher precedence selector for the actual styles CKEditor was setting.

comment:5 Changed 9 years ago by Piotrek Koszuliński

I don't think that it is feasible. I can name a couple of problems:

  1. It isn't possible to create such high-specificity selector prefix for all editors on the page, because editors can be dynamically created in many places.
  2. This would be a performance killer. Parsing CSS, writing it, forcing the browser to reapply all the styles...
  3. All that should happen when loading the page and this is the most crucial moment for good UX. We can't complicate it.
  4. Parsing CSS is a pretty tough job itself.

This could only work if it was done by the builder, but it's a lot of work and not that useful feature, because all selectors would be hardcoded.

comment:6 Changed 9 years ago by Chris Graham

I didn't think of '1'. That's a good point. It could be worked around by shifting the burden onto the implementor, make them pass in the base selector as an optional editor setting. They could work one out that is common to any editor they load, being able to make more assumptions. Perhaps they could even do it dynamically and internally cache it.

But I don't think I agree with 2/3/4. The browser is already parsing the CSS, as there is a W3C API for accessing and changing this. My company's CSS (ocPortal) for example has a dynamic CSS editing/highlighting feature that works off of it and I never noticed it being slow to go through. I think we'd only be talking a few milliseconds, and if it's on an editing context, it'd be less performance critical than the main frontend site.

comment:7 Changed 9 years ago by Piotrek Koszuliński

But I don't think I agree with 2/3/4. The browser is already parsing the CSS, as there is a W3C API for accessing and changing this. My company's CSS (ocPortal) for example has a dynamic CSS editing/highlighting feature that works off of it and I never noticed it being slow to go through. I think we'd only be talking a few milliseconds, and if it's on an editing context, it'd be less performance critical than the main frontend site.

I didn't know about this API. I remember that the last time I heard about working with stylesheets from JS it was a huge pain due to critical incompatibilities (and it was actually an opinion from a guy from W3C :D). What APIs do you use?

BTW. In the meantime I thought about one more thing. Dialogs' and other panels' elements are inserted directly into the body. So we can't prefix most of the selectors and I'm not sure if we'd be able to automatically decide which selectors can be prefixed.

comment:8 Changed 9 years ago by Chris Graham

http://www.w3.org/TR/DOM-Level-2-Style/css.html

Ah, I didn't think about where you tied in the dialogs. That pretty much undoes my suggestion, although you could intentionally over-complicate the node structure you put it in with (extra CSS class, extra HTML attribute to select against, extra nesting) just to get the selector specificity score up, and then statically put that through your CSS. Would be a bit messy though.

Note: See TracTickets for help on using tickets.
© 2003 – 2022, CKSource sp. z o.o. sp.k. All rights reserved. | Terms of use | Privacy policy