Theme CSS interferes with block editor forms
Permalink
Hi all,
I've been converting a static site into C5 and experiencing problems with the my CSS overwriting the CSS used in block editor. There are two cases where this is proving especially problematic:
1. My site uses a reset.css file (based on Eric Meyer's reset code) to remove default browser margins, padding, borders, etc. But because C5's block editor CSS isn't self-contained it's layout is getting messed up.
2. In my main global.css file for the site I specify styles for headings, labels, form elements etc. Again, the C5 block editor's CSS styles are generic definitions so they are getting overridden, messing up the forms further.
I'd prefer not to have to prefix all my CSS definitions with some custom class or id attached to a wrapper, as this will add a lot of redundant code to the CSS.
Does anyone have any more elegant solutions to this?
Many thanks :)
I've been converting a static site into C5 and experiencing problems with the my CSS overwriting the CSS used in block editor. There are two cases where this is proving especially problematic:
1. My site uses a reset.css file (based on Eric Meyer's reset code) to remove default browser margins, padding, borders, etc. But because C5's block editor CSS isn't self-contained it's layout is getting messed up.
2. In my main global.css file for the site I specify styles for headings, labels, form elements etc. Again, the C5 block editor's CSS styles are generic definitions so they are getting overridden, messing up the forms further.
I'd prefer not to have to prefix all my CSS definitions with some custom class or id attached to a wrapper, as this will add a lot of redundant code to the CSS.
Does anyone have any more elegant solutions to this?
Many thanks :)
Thanks - that's where kinda where I'd gotten to as well. Unfortunately, I'm using a CSS grid framework and some fairly complex CSS which gets messy when everything needs prefixing with #wrap. Might have to bite the bullet though!
This reply is coming in pretty late, but I figured that it may help others who find themselves in similar situations. I am going to take the same advice, to wrap all of my styles inside of a body id.
My suggestion as to how to do this would be to use SASS instead, which makes it really easy to wrap the entire file under the one id. Basic gist would be to put this at the beginning of each css file (renaming them as scss, and then putting it through some SASS conversion tool):
Hope this helps save someone else from the large amount of work it would take to convert every style to be cognisant of the body id tag that it's in.
My suggestion as to how to do this would be to use SASS instead, which makes it really easy to wrap the entire file under the one id. Basic gist would be to put this at the beginning of each css file (renaming them as scss, and then putting it through some SASS conversion tool):
body#myThemeId { **file's regular CSS** }
Hope this helps save someone else from the large amount of work it would take to convert every style to be cognisant of the body id tag that it's in.
My main question is why something like this isn't done on the back-end side, so that we don't have to code around it or worry about prepending whole templates to avoid collisions.
Am I the only person thinking this???
Am I the only person thinking this???
No, it doesn't make much sense to me either. Loads of people are using reset styles and CSS frameworks now and it makes converting an existing site more of a headache than it needs to be. Also, requiring a wrapper style for everything creates unnecessary bandwidth overhead for front-end users when there's large amounts of CSS, and could even affect rendering performance.
http://www.concrete5.org/documentation/developers/pages/themes/...
"An easy way to fix this is to wrap the template markup with a DIV with an ID of page or "wrap" just inside the BODY tag.
Then in your main.css and typography css, prepend the #page or #wrap to each css rule, to limit its scope. This will ensure that these greedy styles only affect the theme's elements, rather than concrete5's toolbar and dialog window as well."