As you may have seen throughout the multiple discussions on here and the Facebook community, we are currently planning on reviewing the way block styles are applied.
Currently, all block styles are bunched together in the cc-main.css stylesheet to allow you to use your block classes globally.
Not to be confused with Global Classes that separate from any block.
While this was necessary before Global Classes were introduced, it seems to be confusing for quite a number of users and also adds bloat for installations that use a lot of block styling as they are all loaded together inside that main stylesheet.
We’d be interested in having your participation in this poll as this is a defining moment in how block styles (classes) will be handled in Cwicly.
You’ll notice a binary choice since after looking at it closely, it becomes apparent that it isn’t realistic to have both options available by choice.
Thanks in advance!
- Block styles loaded globally through the main stylesheet - no change
- Block styles loaded uniquely on the post/template they belong to
Wouldn’t this be dependent on how the class system works in the future?
The way the class system is built and how it currently works, the “correct” solution is block styles loaded uniquely.
Each option comes with benefits and downsides, but again:
I can’t vote for it if I don’t know how the class system will work in the end, this goes hand in hand.
All (or most of) these votes have been made with the current system in mind.
In case someone argues with “yeah, but block classes will be block classes”.
This most likely will be the case.
The point is: What happens to the other 2 class fields and how do they work then?
How can one utilize them and integrate them into the personal workflow?
It’s the construction as a whole that matters.
For me, this is something to decide when the new system is introduced.
Collecting opinions at the very beginning and based on something different can’t lead to something practical.
I might miss something, but it’s my personal opinion anyway.
I think if the generated css for a block is based on an autogenerated class, then it should only load that on page level. If the class is added/edited by the user, then it should be global. (as it will probably be reused)
Note: I haven’t put thought in the idea, is just a quick feedback.
Please bear with me on this one.
I might not have clarified the situation here.
The class system logic won’t be changing, and the underlying 3 class roles is something I think works, but is simply not well portrayed and understood.
This is where the work has to be done.
This poll is meant to make sure that our next move, which is moving all block styles to their own page specific stylesheet as this will remove the confusion of the additional class field’s role, is something we can go through with.
Thanks a lot for taking the time and making it more clear for me @Louis.
I think dedicated stylesheets per post/page/template should’ve been there from the point where the global classes have been introduced.
This would’ve took away so much confusion but I understand that it probably was necessary to test things out first and collect feedback.
Also, this approach will limit your classes to a specific area.
But, as mentioned above, therefore there are global classes, which again would make the situation clearer for everyone.
So all in all, it definitely makes sense if I understood everything correctly.
You also have my vote to streamline the class system experience, it’s obvious something needs to be done and this poll makes a lot more sense to me now.
In agreement with the above. Local classes per page and global classes site-wide is both the most instinctive interpretation of the framework, and will resolve a lot of confusion in the case of unpredictable results from copying and pasting blocks between pages, which I and my team have experienced.
I agree. Block classes per page and global classes globally. I hardly ever reuse block classes because I never remember or pay attention to which block is the “master” block.
The only issue I’ve run into with global classes is trying to style icons. I’m not sure if this is an option now because I haven’t looked in a while, but ideally the global classes, relative styles, pseudo classes/elements would have every possible option you’d need. I’m not sure if that’s feasible or not, but that’s all I’ve run into so far.
Very good point @msguerra74 as I think was brought up in the last live about styling specifics in the Global Classes.
This will have to be introduced before the switch to per page block classes.
There seems to be issues when using the virtual classes on reusable blocks. (all styles are striped)
I think it might be related to this. (but just after yesterdays updated I noticed it)
Virtual classes can only apply if their related stylesheet is loaded.
Reusable blocks are post/template agnostic, and load their own separate stylesheet file.
Are the virtual classes coming from outside the reusable block? If so, they won’t be loaded since the post/template they belong to isn’t being queried → stylesheet not enqueued.
This has been the case since 188.8.131.52
If the virtual classes reference is defined within the reusable block, they should be applied correctly.
Yes, I’m referring to classes used inside the reusable block.
The issue actually seems to be that the referenced class it keeps changing each time the page is edited.
So if I have for example the reference block with class .a,1 save, load the page and it’s ok.
If I re-edit the page, save, load the page, the class .a1 is changing to something else. (so the links blocks also don’t work anymore)
Definitely something we should look into. Thanks for the specifics @alex.
Just a note, this is with “Remove class & id” enabled. (I guess it’s more related to this then the current topic) But the issue only become visible after yesterday’s update.
Thanks @alex. There is a bug that was introduced with yesterday’s update when a class is renamed within the reusable block. The discrepancy happens on save. Will see where it’s going wrong.
Appreciate you taking the time to explain
This should be fixed in 184.108.40.206.1. Thanks for letting us know!