I’ve spent some time already this morning looking at blocsapp’s handling of classes in the UI, how it generates code and my mental model of how this should work.
I can say now that my mental model of the class editor was wrong and it was wrong because I didn’t read your documentation or look at the videos and I have ‘gotten away’ with using blocks classes as I have through sheer luck.
I generally kick off with the lg view and if I want to make a class I do it and generally most of my efforts are spent on the desktop version and then I move downwards (OK, not ‘mobile first’). In most cases I haven’t used classes much and tweaked things using the attributes panel.
This time around things were different and I had an intenion to make a single consistent layout that was independent of breakpoints. My mind model was that classes were global and not subject to media queries in the blocsapp world. So a major mismatch between my mental model and the way blocsapp handles classes.
So total mayhem and until I went back and looked at your code generation and documentation I had believed you were misrepresenting things and that was wrong.
I suspect most users aren’t using custom classes and I suspect many won’t realise how the class styles percolate through breakpoints - I don’t think it’s really mentioned in the docs.
Now back to my issue - a consistent class definition that exists across all breakpoints.
Blocsapp hijacks the generic, global class definition and uses it for the lg breakpoint. I kinda understand why but I think it’s wrong.
It means that in the blocsapp world there is no base css custom class accessible to the user except when editing in the lg view.
blocsapp is making use of a convenient technicality in the lg view to use the generic global class rather than create one inside the media query (using min-width, rather than max-width as used for the other breakpoints).
So the only way to create a ‘global’ class style is to understand what blocsapp is doing in the lg view, get that the values are cascading to lower breakpoints.
In my case it’s all too easy to be checking the view in SM say and have the class editor open and then I’m screwed if I edit the class without switching back to the LG view.
So I would say that blocsapp co-opts in the global class as a convenience in the lg view and makes having a single cross-breakpoint style quite difficult.
I wish blocsapp gave access to the global class - a more advanced view in the class editor that enabled global changes regardless of view being displayed. A global/local tab could do that in the class view.
Anyway, completely my bad for having the wrong blocsapp mental model and not reading the docs, but still some annoyance that access to the global class style is dependent on switching to the lg view ( yes I know that’s how cascading works, but I never imagined that any editor would insist that the user switch to a particular view to access a global css class ).
Anyway, I now know what’s going on, my mental model is adjusted and I will ‘suck it up’.
It is actually quite impressive how you handle cascading in the UI between breakpoints.
Feel free to delete this thread.