Editor, pseudo classes issue

From old feedback: https://feedback.cwicly.com/boards/bugs/posts/editor-pseudo-classes-issue

I was just playing a bit around and noticed some issues.

My pseudo “after” elements get some styling attached inside the editor, see image. No clue where it comes from, might be an issue with the Cwicly Div Block.

Pseudo classes, like hover:before or hover:after, work fine inside the editor. On front-end, the CSS is just not there. This was tested with headings, divs, etc.

I also was trying to add a background image to a section block with the pseudo before class. Also no luck.

Attached images

Referring back to this.
There is indeed an issue with the content property not being added to the Section block. This will be addressed.

For the other issues concerning properties not being added, this is because the Section block is a conjunction of a main div and a wrapper.
This means that we apply some styles to the main div, while applying others to the wrapper.

It may be best to set all properties that apply to pseudo elements (::before, ::after) to the main div.

Great news, thanks!

I am aware how sections work and I think the issue with the section pseudo classes, which were not applied, was the only one which was not addressed in this topic. Not sure, but I think this is not something I have mentioned here, maybe just a misunderstanding.

The only thing which would be left here, is the following.
It is about the pseudo after element that gets applied to every single block, which is a problem inside the builder.

Specifically replying to this video: Loom | Free Screen & Video Recording Software | Loom

The move to styles.css is positive, but still requires keeping up with Gutenberg style changes if one wants to modify the pseudo classes styling applied…
But you are correct, resetting the ::after element seems to be the way to go, and we might be including this with Cwicly since the styles applied to the ::after element are not in use with Cwicly blocks.

Thanks for claryfing @Louis.
Alright, now I see what you mean. Gonna wait how things turn out as soon as the fix has been pushed to see exact behaviours on a real page.
But you are right, I might have missed something in my consideration.

This might be the case I couldn’t figure out for what reason this exists, since I use Cwicly blocks almost excusively.
It would be a real improvement to see this in Cwicly at some point and I am happy to see you share the same view.


Thanks @Louis for the fix, now it definitely works as intended.

It was all about the CSS content property which was not applied at all.
Now there are much more possibilties to style the main section block with pseudo elements in combination with relative styling, when adding the pseudo element inside the relative styling modal.

That’s exactly what I had in mind, sorry if there were any confusion regarding my screencast, just wanted to demonstrate that there is no effect after changing some styling and totally forgot at this moment some of the properties wouldn’t change anyway, since they are reserved for the child wrapper.

As soon as the the default Gutenberg ::after styling issue is tackeled, I’m finally able to start the implementation of my button collection to Cwicly, since the option for <span> tags just arrived with the newest update for all RichText blocks :heart_eyes:


1 Like

Hi @Marius, thanks for persisting :wink:
Your screencasts and reports have been so helpful to make Cwicly more stable.

The ::after styling is going to be more of a headache sadly, since after checking it again, this is what the Gutenberg team are using to style the “selected” state for a block…
This makes separating from it that much harder.
I think that we will eventually have to take over the selected, hover state styling since using pseudo elements on the blocks is not a viable solution (but understandable for simple Gutenberg blocks).

I’ll be keeping this thread updated on our findings and what the best solution is going to be.

Thank you for your kind words @Louis, even though sometimes I have the feeling that I might be kind of annyoing and strenuous.
So this is highly appreciated :smiling_face:

Thanks for the update here and also for being transparent.
I understand the situation and it’s totally fine if it turned out to be harder than expected.

With the update, you added the canvas block highlighting on Navigator block hovering, I actually thought you already found a way to separate them.
Hopefully there will be a solution at some time, since this is something the user can’t fix on its own properly.

I am confident, Gutenberg will move away from that implementation as it evolves, but as we all know this could mean years.

As a temporary solution / workaround, I will just reset the styles of the ::after element.
I hope it works out and will do it for now.

1 Like

Has this finally been resolved? :open_mouth:
Seems like the indicator is now attached to the actual element instead of the after pseudo element and only shows up when hovering, not as a selected block state.

Unfortunately, it still keeps changing styles (on hover), but it doesn’t break things anymore when styling the after pseudo class. So it has become rather a minor thing now.

Correct @Marius! Thanks for bringing this up again.

Only when selected will the ::after styling be applied.
The Gutenberg team is slowly removing these unnecessary additions so this is a big plus!


Indeed, really happy to see some progress here, gives me a positive feeling this gets fully sorted at some point :crossed_fingers:

1 Like

Hello @Marius,

With 1.4, and for various reasons, we decided to override Gutenberg’s default highlighting process with a solution that we believe is least intrusive.

This issue should now be resolved.


1 Like

Thanks for pointing out @Louis. This is great news. We finally have the ::after back :heart_eyes:
I like your solution, shouldn’t interfere in the regular building process.

If anything comes up in this regard, I’ll check back :raising_hand_man:

1 Like