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.
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.
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
Hi @Marius, thanks for persisting
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
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.