A few differences between editor and frontend

[yankiara]

Cwicly Plugin version: 1.2.9.3

Hi,

Here are a few things I noticed that don’t match frontend in backend editor.
Gutenberg is not that easy to tame

1. Before and after in inline elements

Backend:

Frontend:

I guess it is due to the display: block of the div which causes a line break.

Not sure whether it is WP or Cwicly, though

2. Paragraph margins

Here the .is-root-container messes with my custom CSS.

3. Rules based on last-child

I could solve this with different targets, but here, the “+” button seems to add a div in my grid, so my last item is not the actual last item, and order property was not applied to the right element.

[yankiara]

This is actually a critical issue for clients, especially when editing content like page or post.

Also found this, which is a bit brutal

A last one: If I remove the .is-root-container p rule to get my margins back, blocks margins add up instead of collapsing:

Changing display back to block solves the problem

[yankiara]

So, here is quick fix for the most basic issues I’ve mentionned above:

.is-root-container.block-editor-block-list__layout {
    display: block;
}
.is-root-container p {
	margin-block-start: 1em; /* Set your own p margins here */
	margin-block-end: 1em;
}
:where(ul,ol):not([class]), :where(ul,ol).block-editor-block-list__block {
	padding-left: 1.5em; /* Set your favorite list padding */
}

NOTE: I use :not([class]) because unfortunately, nav menus & image galleries (and maybe other blocks) still use ul tag to display elements (which seems a bit prehistorical to me!) so I need to exclude them.

And here is my actual SCSS (which also handles headings spacing and removes margins for first and last children):

h1, h2, h3, h4 {
	margin-block-start: 1.5em;
	margin-block-end: 1em;
}
p, :where(ul,ol):not([class]), .is-root-container p {
	margin-block-start: 1em;
	margin-block-end: 1em;
}
:where(ul, ol):not([class]) > li:not(:last-child), :where(ul, ol).block-editor-block-list__block > li:not(:last-child) {
	margin-block-end: 0.75em;
}
:where(p, :where(ul, ol):not([class]), :where(ul, ol).block-editor-block-list__block, h1, h2, h3, h4) {
    &:first-child {
	    margin-block-start: 0;
    }
    &:last-child {
	    margin-block-end: 0;
    }
}
:where(ul,ol):not([class]), :where(ul,ol).block-editor-block-list__block {
	padding-left: 1.5em;
}

Maybe you have some better way to do this?

[yankiara]

Small addition

I usually change the list bullets style to match my global design and add a bit of life, for instance:

ul:not([class]), ul.block-editor-block-list__block {
    list-style: none;
    padding: 0px;
    & li:before {
        margin-right: 0.5em;
    	color: var(--c-bullets);
        content: '\27A2';
    }
}

But due to the before/after issue mentionned above, there’s again a line break after the bullets

So here is a fix for basic blocks:

:where(p, h1, h2, h3, li) > .block-editor-rich-text__editable {
    display: inline;
}

Now, backend looks exactly like frontend:

[owynter]

Great stuff.
I would consider my CSS knowledge “intermediate” at best, so I was only able to keep up with some of that

I’ve found some fiddly things on list items, myself, and have had to add some workaround through trial and error. Your point about Gutenberg being “not easy to tame” is so right. I can never be sure which is a Cwicly issue, and which is just Gute being Gute.

[yankiara]

@owynter

I can never be sure which is a Cwicly issue, and which is just Gute being Gute.

I see what you mean! I always have a WP test website tab open close to my Cwicly test website so that I can quickly check what comes from what

Here, except maybe for the before/after issue which is a bit ambiguous, all problems seem to have been introduced by Cwicly, so hopefully they can Cwicly fix them

[yankiara]

I found another issue with styling added in script tags inside editor.

Those script tags mess with pseudo-classes like :first-child, :last-child, :nth-child, etc.

Maybe all styles could be added to a global script tag outside of rendered markup?

[yankiara]

Bump @Louis & @Araminta,

I’m very concerned that this report is ignored.

This is getting critical when delivering to the client, especially the last issue…
Is there something we can do for this?

HTML structure shouldn’t be altered by those script tags, even inside the editor.

[Louis]

Hello @yankiara,

This is a matter of great importance to me and I have previously shared my concerns and opinions on this topic in other discussions. You can use the search function to find them. However, we must prioritise certain issues, features and respect the process.

While I appreciate your engagement in multiple threads, I have noticed some frustration in your comments. I would kindly request that you refrain from using derogatory language such as referring to Cwicly as “cheap” and implying that we are not properly addressing reported bugs, or somehow disguising them into fixed bugs.
Please know that we value all contributions and feedback from our users, and we appreciate the time and effort you have invested in participating in these discussions, but attributing false intentions to the team and I should not arise.

I appreciate your understanding and patience, @yankiara.
We strive to create a supportive and collaborative community where all users can share their opinions and ideas in a respectful manner, let’s keep it that way.

This will be addressed, so please bear with me

[yankiara]

Sorry @Louis,

No offense, I wasn’t implying anything at all

As nobody replied to this report, I just wanted to revive it.
And I wrote “forgotten’”, not disguised in fixed bugs.
And I wrote “a bit cheap in some aspects”, not simply cheap.

But yes it is true I feel frustrated in some ways, but it is matter of statistics: the more I use Cwicly, the more I learn it, the deeper I go… So now I use it on more complex sites or for bigger clients, so I face new problems and have new expectations.

But as I wrote it, I’m very confident with the team

Please forgive me if I’m too pushy or insisting.