Fred and custom styles for the editor view

Sometimes the Fred editing view is so radically different from the correct styling that it makes it difficult to manage. Is there a way to add a custom stylesheet to make the editor view at least somewhat similar to the final structure?

What it is supposed to look like…
preview-view

What you get in the editor…
editor-view

And there is a similar, possibly related, problem… the bottom item can get its context menu blocked.
blocked-menu

It’s been a while since I used fred but there used to be a .fred parent class wrapping everything when you’re editing with fred that you could scope off of. You can perhaps use that class to try and bridge and normalise the differences?

1 Like

Thank you. I will try that and see what it can do. A “inspect element” should give me the relevant Fred classes to use in my custom.css file.

Did you look into the HTML attributen data-fred-block-class?

1 Like

Not for this purpose, no, I wasn’t aware it could be used like that.

No, the data-fred-block-class replaces a class after Fred is finished with it, the class tag is empty while Fred is active.

1 Like

I made a start, after two hours of trial-and-error.

.fred--block_content article figure { width: 21%; }

At least now the blocks are sized properly. The next step is to figure out the display: table parts to line them up horizontally.

No, that won’t do the job, the Fred container is taking up the whole width of the dropzone. Well, it’s a step in the right direction, anyway…

Hmm the data-fred-block-class should be the answer here I think. Though it does depend how you’re managing your columns of course.

If you do an “inspect element” of the HTML element in question while in Edit mode, you can see the the empty class attribute, and the data-fred-block-class holding your classnames. In Preview or when not logged in, the element has its classnames as originally assigned. The whole purpose of the data-fred-block-class is to hold your classnames while Fred is in edit mode.

Yup, because Fred divs wrap around the elements when in edit mode.
Using Bootstrap as an example, the following won’t work in edit mode if not using data-fred-block-class. (if you’re dropping columns into a row dropzone)

<div class="row" data-fred-dropzone="content">
    <div class="col-6">
        <!-- col#1 -->
    </div>
    <div class="col-6">
        <!-- col#2 -->
    </div>
</div>

I can assure it it won’t work in Edit mode either. However, I have a MODX designer in Indonesia, Sopyan Maulana, aka mandollarian, helping me with customizing the CSS and he’s doing a marvelous job.fixed-edit-style

In the Bootstrap example, whereas the above one won’t work, this one should work:

<div class="row" data-fred-dropzone="content">
    <div data-fred-block-class="col-6">
        <!-- col#1 -->
    </div>
    <div data-fred-block-class="col-6">
        <!-- col#2 -->
    </div>
</div>

That is very disturbing. Last night when I was working with it, in a browser “inspect element” I clearly saw several places where there was an empty class attribute, class="", where there was a data-fred-block-class=“whatever”. So I went back just now to get a screen shot of that, and now I see all of those class attributes with their classnames. So clearly, at some point, the classes are empty, then they get populated. Maybe after the data-fred-block-class is added to the element’s markup and before is saved for the first time?

Anyway, classnames or no, the blocks were still having their styles overriden by Fred css, so the more specific selectors in the custom.css in turn override the Fred css. It’s just a matter of inspecting the elements involved and determining the best selectors to use so that they only affect those under fred–block or fred–block_content and not in preview or visitor mode.

We’ve also found that Fred does not much care for display: table, so the custom css overrides that with display: flex and all is well.

I knew I saw this! In Fred edit mode, certain HTML divs with a classname of “container” lose that classname. This prevents the layout from being anywhere close to what it’s supposed to be.

Hmmm… what’s the reasoning for using data-fred-block-class on the dropzone?

Because without it, the classname doesn’t get restored after Fred eats it in Edit mode. Otherwise known as “trial-and-error” and “search the docs”.

There is a huge fred.css that is not a file, can anyone confirm my suspicion that it is generated at run-time by the Fred javascript?

I can see it being used in the browser inspector, as well as get the code for it. It has attribute selectors, like
[data-fred-dropzone] {...
and
.mce-fred--modxlink .choices[data-type*=text] .choices__button {