HI All – As I continue to learn Blocs, is it just me or have others found that using ‘classes’ for detailing of typography & positioning elements begins to really become a challenge all unto itself in regards to naming the classes and remembering when and where a class was applied, and recalling all the settings for that class so as to not apply it to an additional element that shares some of the attributes but not all of them?
The deeper I get in building on the fly – meaning no pre-conceptual sketch or using a more professional sequence of building a schematic version in some kind of application like photoshop or other website ‘napkin sketch’ software prior to constructing a site directly in Blocs – the more complicated using classes seems to be. I can see the huge advantage of planning a site in some other software, and then itemize elements so as to pre-plan a naming scheme for using ‘classes’ in an efficient way. Is this how most of you use Blocs?
Is there a best practices approach for using/naming ‘classes’ for creating a site from inception to completion only in Blocs?
I agree work needs to be done on organising custom classes. They are great in theory, particularly if you are adding a fixed behaviour in a number of panels for example, but as sites become larger they can become a pain to manage with unintended consequences, unless you really stay on top of it.
For example, you might create a class called toppadding50, but to cater for different devices that might only add 20 points in mobile. That doesn’t necessarily mean you want the same behaviour everywhere on the site, where you might only need a particular spacing on one item, so I would rather have the control organised in the side panel, but that is just not possible at the moment.
For naming I would suggest keeping class names linked to the area you want to use it and make it very specific, so it might be something like email-form-side-padding-10-margin-auto.
This would really be easier if each bloc type had a specific name and this is a source of considerable frustration to me that you can have 9 gallery blocs for example, but not one of them has a name and Blocs won’t allow you to use the same ID twice if you decide to name it yourself.
HTML/CSS IDs are supposed to be unique regardless of whether they are created in blocsapp or any other software. If you want multiple entities to have a common behaviour, then assign a class.
This is not so much about blocsapp but the way HTML/CSS works.
It’s easy to be badly organised, but we should blame ourselves. I do. I often realise that my projects could progress more smoothly with better planning. I don’t blame blocsapp for my bad practices.
To be fair, though I do stuff like this, it’s bad practice altogether.
If you name your classes according to the use and not the behaviour, you get better control altogether. So for example you might have a class that is gallery-item-mobile and gallery-item-desktop. Then you assign characteristics using that class. So gallery-item-mobile will have top padding 20 and gallery-item-desktop would have top padding 50.
The big advantage is that if you decided to have top padding 30 it’s easy to do. If you use classes like toppadding20 you have to go all over the design changing the classes being used to be toppadding30.
I sometimes take these shortcuts, but I deserve a slapped wrist and so does anyone else creating classes like that - it’s bad practice.
I agree with much of what you say, however I think there are too many situations where we use custom classes that could be better organised from the side panel if the controls existed.
As an experienced user of Rapidweaver, every stack has a name provided by the developer, so if I talk about Grummage, Peek-A-Boo or Ivy everybody is on the same page. Brics do have names, but we have umpteen bloc types that are completely nameless and that doesn’t help when creating or organising custom classes. I might tell you I’m having an issue with a carousel bloc, but then have to describe it as “the one with three dots on the image and text underneath”. It seems ridiculous that I can open a project, click on a bloc and not know what I have used.
Classes are my most used features using Blocs. @pauland makes a great point. When my sites get to many classes and seem hard to find it’s normally “my own fault”. If I would take more time in the planning stage and have a better vision I would be able to organize and cut down on the amount of classes I use.
Now, if you had the ability in the panels to adjust a Bloc padding in the three break points without having to create a class that would rock. But I don’t think that’s possible?
As far as the Blocs themselves, you have the ability to give each Bloc a unique ID.
Flashman I feel your frustration, but sometimes it’s just easier to be better organized and try to use any software as efficient as possible.
I think the bloc-type ( or any entity type) is less important than bloc use, but I think that it would be great to have unique names for blocs, but not necessarily carried through as classes into blocsap, but just as labels in the software.
It’s not possible at present, but I see no reason why it can’t be done. Actually a lot of messing about could be avoided if we simply had the option to use rem for padding instead of points. Also if we could set up separate sizes for text in project settings, according to device type, rather than one size fits all.
These are all things I do when using Foundation, plus there are simple options to centre elements in mobile or remove padding for different device types all in the side panel with custom override options.
Ah, so my experience is consistent with all of yours, though my usage is vastly different as a non-professional.
My current conclusion is that the software’s strategic approach of providing the tool of ‘Custom Classes’ as a method to customize Bloc & Bric Elements, carries with it a high demand for planning and managing ‘custom classes’ in order to be efficient in site construction, and in order to not be unduly creatively constrained by the out-of-the-box styled elements that can be plopped in place and styled with the sidebar.
I hope this is addressed in Blocs 3, especially for non-professionals like me who look to build a single site from start to finish in a single app, and then maintain it periodically throughout the year(s).
Thanks to all for sharing your professional knowledge & usage & ways of working-with this particular attribute of Blocs…ever so helpful!
Daniel, I think it takes as much effort to avoid doing any planning as it does to do some basic planning.
I entirely get the disjoint between switching from the bloc/page that you are working on and moving to the class manager. I’ve worked on a lot of systems that allow customisation “in the moment” and it can seem perfectly good, but overal it can make for a messy user interface without discipline. If the client decides at the end of the project that they hate the colour/font/whatever that that they chose, revisiting everything can be time-consuming and frustrating, but changing a couple of class definitions can make that change far more rapid.
Often I wish I’d spent a lot more time with a pad and paper and sketched the site out with paper and pencil before proceeding with blocsapp. Don’t avoid doing a bit of planning and try and embrace the power of classes.
I know people would like to see the disconnect between class manager and instant entry of CSS control figures reduced. I understand that. It’s just difficult to see how that can be done and still retain good practice with classes.
I think this is as much about not thinking about ‘local’ web element changes as ‘consistent website-wide changes’.
Try and embrace classes. It will make things easier even if there’s a learning curve at first.
I agree with pretty much everything @pauland has said and obviously no two sites are the same, so you can’t always have a single approach. Nobody is saying Blocs is perfect at this stage and Norm would be the first to agree.
If you are looking at site wide changes, then custom classes are the way to go, but I think it makes more sense in one off cases to have controls in the side panel, especially for spacing and that is lacking at the moment. There is no reason why the two options cannot co-exist if this is properly thought out.
Stacks in Rapidweaver has a useful feature called Partials that create site wide changes wherever they are used, however they can be disabled and edited as desired on a case by case basis without affecting the others. If you like the change and want to use it somewhere else you create a new Partial that can even be dropped into other projects.
I totally agree and would highly recommend that everyone using Blocs, buys HTML & CSS by Jon Duckett, both as initial easy to read and understand introduction to CSS but also as an invaluable reference and reminder when building any type of web site. I think an hour or two reading will get the penny to drop and you will confidently embrace the Blocs classes feature.
The Classes feature of Blocs is one of it’s most powerful features and one that keeps the interface relatively simple and relatively easy to understand. Look at Pinegrow for an example of a web creation app with every setting under the sun and you will soon realise how good the Blocs interface is.
Maybe, however, there could be a way of adding inline code in a similar way to adding an ID or Classes (or possibly as an extra tab in the Classes Manager). So for example, if I want to add some padding I would type into an inline box -
padding: 1rem
or margin:10px
This avoids many of the advantages of using a Class structure but perhaps it adds the flexibility to add isolated settings to elements on a page. It’s also a good way to aid teaching and a try it and see it approach to stuff like fine tuning positioning of elements.
Agreed, but the concept of Classes and basic code are closely linked. I think its a good way to introduce code agnostics to seeing how simple the beast known as CSS, really is.
Would you reconsider your wise advice for someone who is not a professional website creator, and so is exploring using Blocs for only their own single website?
Just wondering what level of user you have in mind for your suggestion? Which btw makes perfect sense to me for someone who makes a living creating websites!!
I do agree with @DanielF here. Knowing CSS or how to code in general will definitely help any Blocs user, but it should not stand in a way of creating a beautiful site in Blocs without knowing anything about it. This is why I love using Blocs so much!
I spent a long time avoiding CSS and HTML. It made no sense to me whatsoever until one day someone on another forum showed how easy it was to do something with a line of CSS code. I persevered and really wish I had pushed myself to learn earlier on.
Do you need to understand any code to create an absolutely fabulous web site with Blocs - certainly not. It just helps when you want to do some fine tuning or make your site look different.
Eldar – Thanks for your response, I was thinking of sending you a private message to explore this a bit further, as a consumer of your Mastering Blocs videos.
But, I can reply here regarding your comment that “Creating a beautiful website in Blocs”…just to say that this is really not the standard in which I started this post, as it is way to broad and non-specific to the question of ‘how do folks manage class naming schemes, when making custom websites of their own?’
My amateur method is to do all the work on screen within the app. What I’m bumping into with Blocs is that this natural way of working doesn’t really work, causing all sorts of headaches.
I was wondering how others are dealing with this, and looks to be that professionals solve this problem in a very professional way – learn code, and plan plan plan their sites before building it in Blocs.
I think there are different levels of “learn to code”. You can defiantly benefit from being able to look at CSS and HTML, and tell a bit about what its doing. That’s more what I would call reading code.
As for planning, I think that’s missing in a lot of sites. The tools we use like Bloc’s make it easy to just open up and start throwing a site together. Site should be planned out in advanced, from keyword research (if search engines are important to you) to a sitemap.
As for Class naming, BEM (Block, Element, Modifier) is a popular naming convention with folks who code sites from scratch.
