davidjb
commented
7 years ago My solution to date has been to rebuild the Edit+ styles to integrate with the JCU Web Framework. This involved stripping out most of the 'reset' CSS used in the easyedit.css and all the hard-coded styles that applied to the WYSIWYG field (eg where styles for things like the blockquote were present), and creating workarounds for any further conflicts between Edit+ and the JCU Web Framework (eg Edit+ uses 'row' and so does our Framework).
This solution is fairly robust, but is prone to being affected by any Matrix upgrades and needs to be kept in lock-step. Core Issues:
- Edit+ styling conflicts with the JCU Web Framework
- Edit+ hardcodes a lot of dimensions, spacing, etc; pixel perfect design didn't fit that well with our responsive framework
- Edit+ (Viper) and its text area fields do not separate styles from the main Edit+ UI (eg like TinyMCE does with a nested iframe)
- Prone to breakage on upgrades or any changes from Squiz; detailed testing will be required…
Pages with any form of specialised CSS display fine on the frontend but display without styling (or with incorrect styling) in Edit+ or within the admin Viper UI. The consequence of this is that users see content that looks one way in the editor and looks completely different in the rendered page. A simple example is the blockquote and here's the comparison:
In Edit+
On rendered page
In a more complex example using HTML and the Bootstrap grid system from the JCU Web Framework, because divs are not displayed or laid out as you expect, the result is a string of content down the page that bears almost no resemblance to the final page.
Not having client-specific CSS in the admin UI is less of a concern, as the user is probably technical anyway, or else can switch to using Edit+ to see things correctly.