Editing CSS page in version 7


In version 5, I was able to enable a .css page to quickly edit it while in surreal. In version 7, it doesn’t appear that .css pages can be enabled for editing. I know I can edit it elsewhere, but this was a handy feature to have for quick access to make changes.


This ability was left out of 7 because a lot of designers are modifying CSS/JS files locally or generating them with a build process outside of Surreal.

It also created confusion for clients who ended up having access to those “pages,” and in at least two scenarios clients inadvertently broke important scripts because of it.

I’ll wait for additional feedback before making a final decision on this, but even if this makes its way into 7 it will need to be rethought so only admins can manage code.


In v5, I was able to set up styles for my clients to use from the drop-down menu. In v7, I haven’t figured out how to allow them to even select a headline (H1) style. Also, I added a color (in DreamWeaver) to a hyperlink. It’s fine until I open in the CMS and the link disappears. My biggest concern is how to allow my customers to use their custom CSS styles.


Follow up on my comment about the headline style not being available. It is available in some of the editable regions but not others. The headline styles show up on the divs that are entirely editable. But does not show on a div where only one line of type is editable. It appears the additional styles only show up in a div but not on a “p” or “a href” within a div. I’m guessing there’s a good reason for that. :wink: However, the font attribute of yellow color keeps dropping out when I add the link. V5 allowed the client to change the color, size, background color and font. Not that I want them messing with the design too much, but I’d like to give them some flexibility.


Custom Styles were removed. The ability to toggle any class on any element (and the overall way elements were selected) was way too flexible and prone to misuse by clients. I’d often see users applying classes on elements they weren’t intended for. I’d also see users selecting the wrong elements (e.g. a child element instead of its parent) and then wondering why the styles weren’t being applied properly.

A better approach is to use blocks. This gives you complete control over the structure of the markup and the client doesn’t need to worry about whether or not they’re selecting the correct elements and classes. Just insert the block and update the content.

You can couple blocks with repeatables and lockables, so they’re quite powerful and ultimately offer more flexibility for you without letting clients go crazy with setting arbitrary classes on random elements.

This is by design as well. If you’ve enabled an element that doesn’t support headings as child elements (e.g. <p> or <span>) then those options won’t be exposed in the toolbar. This behavior is consistent with version 5.