Blocsapp handles classes wrongly

If we create a class using the class editor in blocsapp, it is propogated with the same name across all breakpoints.

If the class is then edited the change only applies to the particular breakpoint being viewed, so if you wish to make a change that applies across all breakpoints then it requires multiple edits.

Keeping edits consistent across all breakpoints is a nightmare.

My suggestion is that blocsapp only creates one class and that it is independent of breakpoints. If I want a variant of that class for a particular breakpoint let me make a new class for that situation.

So, I create a class standard-width. I set the width in that class definition. In the lg version however I want a different width and either create an new independent class standard-width-lg or make a standard-width-lg that modifies standard-width.

I hate the way it works now.

If I misunderstand any of this, let me know and let’s get some feedback about this idea.

This is not accurate. Blocs creates Css rules that cascade down. Not up, only down, this is the nature of CSS.

If you find your class styles are not cascading down, another class maybe mutating your styling.

This is also a major advantage of css (the fact styling can be combined and adjusted with various classes)

Take a look at your style.css file, blocs doesn’t do anything that would prevent how all browsers render css.

Also preview your site and try inspecting the element that doesn’t look right. This will let you check for any classes that may be overriding the style.

I hope that helps.

1 Like

Blocs is consistent with the way CSS works and also the way Bootstrap works which is a mobile first framework.

1 Like

OK, take a look at this screen recording.

https://www.ipauland.com/clients/screen-recording-class.mov

I create a class in lg view, then set a width value.
I go to xs view and edit the class and change that width value.
I then look at other breakpoints and the width value is unchanged and different to the XS value.
So my class definition is changing according to the breakpoint.

That’s correct. Because you assigned a style before you added one to a breakpoint.

Once you added a changed style to the xs a CSS media query would have been created for that breakpoint. The rest will retain the original style.

So my point is, how can I edit the class without creating a version that is part of a media query?

In my example I get a custom class, but editing thereafter creates another version for the media breakpoint and I can’t edit the original custom class after it has been created.

How do I stop blocsapp associating my custom class with a breakpoint after it’s initially created?

/* = Custom Styling
-------------------------------------------------------------- */

h1,h2,h3,h4,h5,h6,p,label,.btn,a{
font-family:“Helvetica”;
}
.container{
max-width:1140px;
}
.my-class{
width:200px;
}

/* = Colour
-------------------------------------------------------------- */

@media (max-width: 575px){
.my-class{
width:100px;
}

Have the canvas on LG

The other breakpoints will create media queries as it should.

That’s not how I expect classes to work. My generic version of my-class should be sub-classed in the media query not a carbon clone of it at the time of sub-classing.

Also what happens if I create my new class in the XS-view, then edit it again in the LG view? which version will md have?

You have an IT background right? I suggest you read up on CSS.

Regarding which style overrides… then the last style from top to bottom in the style sheet. With exception to styles that have !important as a suffix.

As norm mentioned. Cascade is the C in CSS.

Which is why being able to add multiple classes is important. You could have a general style class for a card for example and then specific classes that add addition styles for a feature card that overrides the general ones. In which case you don’t have to re set all the styles again

I understand how cascading works, thank you for your insult. I’m putting forward my query and I don’t expect to be insulted for asking questions. I’m disappointed in you Malachiman.

Whether someone has an IT background or not should not be relevant to the discussion.

When I create a class blocsapp creates a custom class for me not attached to any breakpoint - good.

As soon as I try and edit it again it makes a decision that I want a break-specific version of the class but I didn’t make that choice.

It’s not about CSS it’s about blocsapp making unexpected decisions for the user. Unexpected for me, anyway.

If I wanted a break-specific version of a generic class I would create a cascaded version with a different name based on that generic class. I don’t think blocsapp should be hijacking my class on breakpoints.

It’s my view.

Currently I can’t edit the generic class without returning to the LG view ( or maybe the view that existed when it was first created ).

No insult implied. I don’t know what you know. Your comments suggested you aren’t familiar with it. A reference to IT background is acknowledging that you should be able to pick it up no worries.

I’ll leave you too it. All the best.

This is just how CSS works in general. It’s not limited to Blocs, it’s standard in web design.

2 Likes

I think you are both missing the point completely.

I understand that ‘my-class’ in a media query is going to override ‘my-class’ declared as a style outside of a media query.

My point is that blocsapp is deciding based on my media break that I want a new class based on that break. I haven’t said I do.

When the class is initially created it has no association with any media size. Blocsapp is focing me to create a break specific class if I want to change a value.

Malachian, I think, suggested that the lg break was in fact the global version of the class - an implied relationship. So if I want to edit the ‘global’ class I have to change my view.

Anyway, I think it doesn’t work correctly but I am clearly in a minority of one!

Have a good evening.

If you create a new class and set it’s values when the lg breakpoint is selected it will effect all breakpoints. So that’s basically the same as not assigning it to a breakpoint. It just effects elements regardless of screen width.

If you take the class out of the lg media query it’s basically going to do the same thing.

In the latest beta you can actually add additional css via the code editor. If you add your class this way it won’t be assigned to a breakpoint(media query)

I hope that helps :grinning:

Sorry Norm, you just don’t get my point and it’s just me and one other blocsapp user that seems to get the need to be able to edit a class without it being in a media query.

Workarounds are useful but not a substitute for the correct solution ( my opinion anyway ).

I will work around it and hate blocsapp for the need to do it.

Could you explain the technical benefit to what you are trying to achieve?

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.

1 Like

I’ve read, re-read, and read again this thread and I just can’t understand it fully or see the problem!
I haven’t read the documentation fully, and I’m the first to admit I’m not a proper web designer (coming from the land of desktop publishing and only using Blocs intermittently), I know very little code etc. but the classes make perfect sense to me, and I use them all of the time now after my first attempt or two of not understanding.
I sort of see what you’re saying, but can’t see the advantage. To me, the way things stand makes sense!
Maybe it’s my stupid head not understanding- most likely.

Anyway, best of luck battling on, life in general is a learning curve.

1 Like

It does make sense and it does work. It ain’t perfect.

No more battling on, it’s been an interesting thread for me.