Has anyone implemented a custom css framework with the new drag and drop areas? The documentation states that you don't have to use the Bootstrap 2 framework that it comes with. However, It's a little unclear on how I implement the custom css.
Or do I have to reference the Bootstrap 2 class names but use custom css for them?
I have avoided using the drag and drop areas so that I could use my choice of css framework. However, I have a project coming up that will require a few d-n-d areas on some pages so that modules can be swapped out by the client when necessary.
I have avoided using the drag and drop areas so that I could use my choice of css framework. However, I have a project coming up that will require a few d-n-d areas on some pages so that modules can be swapped out by the client when necessary.
I don't see your problem here. Use whatever you want.
Add a framework, go wild, add the class names to develop the modules / whatever else and keep the grid system pre-defined as is..... If you have a framework that clashes... exclude the frameworks grid... or... resupply the grid as the frameworks / rename it. Still not problematic. Presuming a 12-column grid here as pre-defined.
I don't use a grid (column) system at all and I encourage people not to all the time. Also, container queries just put into the W3C spec.... So, now you really don't need them.
Archaic and just bloated. I just make a singleDnD area (or multiple if I have static content -> another DnD afterwards) for a big "Drag your modules here" for marketers with absolutely no grid structure / columning possible. No useless CSS bloat. All of that is entirely encapsulated by modules with a single ugly old bootstrap style wrapper rendered by the initial DnD area that makes me throwup a little every time I see it in the pages source. Prefer to cut it out entirely.... But, whatever.
Side note: Works for me bc I only use big modules rendering large sections with implicitly encapsulated layouts. I kill the old styles that might cause side effects. So, it's really ironic to release a new feature providing people "freedom" with no way to remove the wrapper and implicit side effects.
Anything beyond that I'd just use flex or grid for if I really needed something more rigid. So, marketers just drag and drop section X, Y, ... and change a few toggles. Everybody is happy. I will never understand the naive approach of giving marketers way too much leverage here. Everybody loses and a lot of bad website get made this way.
Beyond this it's only useful if you're making shabby atomic modules that are say "feature column" as part of a "feature section". Or, maybe you have an entire module for an "icon" (why would you ever..... 🙃). Maybe you're dropping those into DnD areas in something like:
dnd_section -> dnd_row / dnd_module -> column -> dnd_module format (taking liberty with ordering here).
Most of these "atomic" pieces of content can just be made with a repeater in a better sectioned format saving people the overhead anyways. For "non-atomic" pieces you have.... a header or something? Yeah, you still don't need a grid for that.
Can argue about the utility of this - I just don't use it and never will. I can make better things without letting people screw up a pretty website, design system, cascades, andeverything else you've built by giving them too much leverage and adding bloat in the process.
It's pointless to do what you're asking. If you're asking about re-doing the grid with another frameworks.
This is entirely HubSpot's fault with implementation here. You're effectively forced to use a 12-column grid, there are many types of grid systems, with default class names rendering said 12-column grid as the documentations states in the _layout.css file or themes CSS folder dependent upon type of development.
You can make any grid system you want.... People used to love Susy for easy grid systems.... Or use a framework providing some flavor of a grid system.... But, why? What's the point. Just to remake the same thing effectively, but add a couple hundred kilobytes of bloat in the process for a marketing website that in no way requires a framework....? Sure I guess....
More abstractly... what makes up a marketing website?
A banner, a blog grid, some case studies, simple navbars and navs, a cta block or two, some cards / features, and other simple stuff? Cool. All of that is < 50 lines of positioning using modern techniques. Anything more complex you're certainly not giving people drag and drop options it's pre-defined in a more complex module 99% of the time hence my original point of atomic modular system beign useless and thus a grid system.
Generally when people use frameworks they do:
Base framework as "core design system" -> overrides as "thematic system" -> aggregates are used to build "X" and that's fine in real development scenarios where all that gets normalized, optimized, mangled, and the last byte is shaved once it's all piped through optimizers removing every ounce of bloat. Most frameworks also have generators for theming / let you divy it up to only what's needed.
You don't have that in HubSpot. So.... provide the framework - use it as is - as a "design system" above then do module / theme overrides and watch how bad your sites metrics are once all those inclusions and chaining happens 🙂 You can prevent some of that by only using framework agnostic classes in the modules and using a single asset file - pre-optimizing to what's needed - but you're still not fixing all your bloat and other problems.
In modern web dev....:
People typically use storybook or other "design systems" encapsulating tokens, components, etc in some JSx / JAMStack framework..... Also not possible in HubSpot outside of the naive "module" approach.
@Ntbrown Thanks so much for your feedback and opinions. I truly appreciate you taking the time to respond. And I am on board with everything you said. With my last few projects, I have used my preferences on the css/technologies, etc and avoided any of the Hubspot options other than modules. As you menitioned, I also found it very strange that Hubspot would offer new features to give developers liberties in how they develop but then still tie the features to an outdated framework.
I will continue to move forward as I have and not worry about the drag and drop areas unless I am forced to. Again, as you said, there are other better options to handle that type of scenario.
I have avoided using the drag and drop areas so that I could use my choice of css framework. However, I have a project coming up that will require a few d-n-d areas on some pages so that modules can be swapped out by the client when necessary.
I don't see your problem here. Use whatever you want.
Add a framework, go wild, add the class names to develop the modules / whatever else and keep the grid system pre-defined as is..... If you have a framework that clashes... exclude the frameworks grid... or... resupply the grid as the frameworks / rename it. Still not problematic. Presuming a 12-column grid here as pre-defined.
I don't use a grid (column) system at all and I encourage people not to all the time. Also, container queries just put into the W3C spec.... So, now you really don't need them.
Archaic and just bloated. I just make a singleDnD area (or multiple if I have static content -> another DnD afterwards) for a big "Drag your modules here" for marketers with absolutely no grid structure / columning possible. No useless CSS bloat. All of that is entirely encapsulated by modules with a single ugly old bootstrap style wrapper rendered by the initial DnD area that makes me throwup a little every time I see it in the pages source. Prefer to cut it out entirely.... But, whatever.
Side note: Works for me bc I only use big modules rendering large sections with implicitly encapsulated layouts. I kill the old styles that might cause side effects. So, it's really ironic to release a new feature providing people "freedom" with no way to remove the wrapper and implicit side effects.
Anything beyond that I'd just use flex or grid for if I really needed something more rigid. So, marketers just drag and drop section X, Y, ... and change a few toggles. Everybody is happy. I will never understand the naive approach of giving marketers way too much leverage here. Everybody loses and a lot of bad website get made this way.
Beyond this it's only useful if you're making shabby atomic modules that are say "feature column" as part of a "feature section". Or, maybe you have an entire module for an "icon" (why would you ever..... 🙃). Maybe you're dropping those into DnD areas in something like:
dnd_section -> dnd_row / dnd_module -> column -> dnd_module format (taking liberty with ordering here).
Most of these "atomic" pieces of content can just be made with a repeater in a better sectioned format saving people the overhead anyways. For "non-atomic" pieces you have.... a header or something? Yeah, you still don't need a grid for that.
Can argue about the utility of this - I just don't use it and never will. I can make better things without letting people screw up a pretty website, design system, cascades, andeverything else you've built by giving them too much leverage and adding bloat in the process.
It's pointless to do what you're asking. If you're asking about re-doing the grid with another frameworks.
This is entirely HubSpot's fault with implementation here. You're effectively forced to use a 12-column grid, there are many types of grid systems, with default class names rendering said 12-column grid as the documentations states in the _layout.css file or themes CSS folder dependent upon type of development.
You can make any grid system you want.... People used to love Susy for easy grid systems.... Or use a framework providing some flavor of a grid system.... But, why? What's the point. Just to remake the same thing effectively, but add a couple hundred kilobytes of bloat in the process for a marketing website that in no way requires a framework....? Sure I guess....
More abstractly... what makes up a marketing website?
A banner, a blog grid, some case studies, simple navbars and navs, a cta block or two, some cards / features, and other simple stuff? Cool. All of that is < 50 lines of positioning using modern techniques. Anything more complex you're certainly not giving people drag and drop options it's pre-defined in a more complex module 99% of the time hence my original point of atomic modular system beign useless and thus a grid system.
Generally when people use frameworks they do:
Base framework as "core design system" -> overrides as "thematic system" -> aggregates are used to build "X" and that's fine in real development scenarios where all that gets normalized, optimized, mangled, and the last byte is shaved once it's all piped through optimizers removing every ounce of bloat. Most frameworks also have generators for theming / let you divy it up to only what's needed.
You don't have that in HubSpot. So.... provide the framework - use it as is - as a "design system" above then do module / theme overrides and watch how bad your sites metrics are once all those inclusions and chaining happens 🙂 You can prevent some of that by only using framework agnostic classes in the modules and using a single asset file - pre-optimizing to what's needed - but you're still not fixing all your bloat and other problems.
In modern web dev....:
People typically use storybook or other "design systems" encapsulating tokens, components, etc in some JSx / JAMStack framework..... Also not possible in HubSpot outside of the naive "module" approach.
