Section global class styling doesn't apply to inner wrapper

Normally when you make layout changes to a section (display, padding, margin etc.) , they get applied to the section’s inner wrapper.

However if you apply the styling to a global class on the section, those layout changes get applied to the actual parent instead.

I can see why this would happen, as you can apply the global class to any element and those CSS properties are universal.

I think though that if you’re applying them when your section is selected, they should be applied to .global-class-name .cc-wrapper instead.

The only alternative would be to show both sections and section wrappers in the structure panel.


I disagree, because you’d lose access to the parent container.

This or adding dedicated virtual and global class fields inside the primary tab, which would be confusing.

Interesting point you bring up here though and I agree that there is room for improvements.

This is just for certain properties though.

If you apply padding to a section via the block class right now, you still don’t technically have access to the parent anyways.

Your point is the global classes if I understand you correctly.

Nothing new how the section block works in combination with the block options.

Applying virtual/global classes to the inner wrapper will remove access from the parent, so what’s the point?

A lot of new issues would be created.

It’s pretty restrictive when working with global classes and the section block right now but your suggestion would restrict it even more.

Working with utility classes isn’t your best option here but you can create section block specific global classes, which also gives you access to the inner wrapper through relative styling.

I think that’s everything we have for now.

Just chiming in here to say the lack of access to the inner container is the dealbreaker for me.
It’s not that big of a deal. Since it’s mostly a (HTML) semantics issue, I just roll my own with 2 divs. I tag the outer one as a < section > and I’m free to do as I please with the inner one.

FWIW, I’ve been doing this for years now since my Oxygen days, for the same reason.

I also feel it’s a real tough problem to solve, unless we move away from the idea of a section block altogether. If you’re coming from other pagebuilders, it kinda makes sense. Although I’ve seen it called all manner of things (like “row”, or “content” or some other such non-semantic things) in other builders.

I think the section block as it is helps those who need it, but for more intermediate-to-advanced folks, we’re probably better off with more granular control of having multiple divs. Certainly, I won’t beat up on Louis about making a more feature rich section block, at the expense of working on some of the more challenging issues.

I would prefer the section to show the outer and inner wrapper in the navigator, but it’s also not the end of the world. Like @owynter said, it’s easy enough to create one manually using divs, or like @Marius said, we can target the inner wrapper of the section block with relative styling. It’s really more of a convenience thing for me.

What I’ve done is create a global section class targeting the .cc-sct class where I set my section defaults and the .cc-wrapper inner wrap defaults either as a second global class or via relative styling. I prefer having my section padding on the outer wrapper so my inner wrapper stays consistent with the max-width I have set for my site. I think when you add padding in the Cwicly settings, it ads the padding to the internal wrapper which I don’t prefer.

And this is definitely one of those things that’s user-specific preference.
I apply padding to my inner container, on a section by section basis, depending on what’s needed. But, I also use my inner container as my “site width”.

My container css stylesheet looks like this, if it matters:

/* Section Container /
.container {
width: 100%;
Inner Container */
.inner-container {
width: 100%;
margin-left: auto;
margin-right: auto;
padding-left: var(–Spacing-Medium);
padding-right: var(–Spacing-Medium);
max-width: calc(1080px + 2 * (var(–Spacing-Medium)));

Max width depends on what I’m going for on a particular site. Sometimes its’ much wider. It has baked in side padding so I never have to worry about smaller breakpoints.

For this reason, I need to be able to add my classes to the inner container. It’s possible I could just target that container and use the same CSS, but then I lose the ability to quickly add the padding I need.

In any event, it’s the workflow that works best for me, so I stick with it. As I’m sure yours does what you need.

Exactly, everyone has their own preferences, so having the ability to easily modify things to suit our needs is key, which I think Cwicly gives us. The only thing I would prefer also, is that the section block spit out the inner container in the navigator. This would help with confusing for those who are not aware that it is 2 separate elements as opposed to 1. Plus it makes styling just a little bit easier.

Just for fun, here’s my section default :sweat_smile::

.cc-sct {
    padding: var(--section--2xl) var(--section--base);

    & > .cc-wrapper {
        @extend .flex--column;
        gap: var(--section--2xl);
        margin-left: auto;
        margin-right: auto;
        max-width: var(--width--xl);
        position: initial;
        width: 100%;

It’s pretty similar to yours only reversed to include the padding on the outer section container. I have additional classes with different padding and gaps, so I can easily add them to the section to adjust any of the spacing as needed. All padding and gaps use clamp also, so they respond from larger to smaller automagically as the device width shrinks.


Love this.

I’m not up on SCSS yet, so I’m doing things the long-form way. Yours is sexy.

I couldn’t imagine doing this without variable units. Defining specific px values for different things is just mindboggling to me.

@owynter Haha, thanks. What’s cool about SCSS is you can write regular CSS in it. The main benefit for me is being able to create functions to do complicated things that would be much harder to do manually. Things where I can plugin certain values and have it spit out what I need. There are also other neat things like mixins that allow you to generate repetitive bits of code with specific values you input as you add one. You can also extend other classes, which basically lets you add stying from other classes without having to write the same code over and over. This all sounds foreign, I’m sure, if you’re not familiar with it, but it’s worth looking into if you write a lot of CSS.

For most things, plain CSS is just fine and works sooo much better than it used to in the “old” days. Before we had CSS variables, that was the main reason I started using SCSS. Now, the main reason is for the function ability. For example, the .cc-sct padding calls 2 variables for top/bottom and left/right padding. Those variables are created from a SCSS function that calculates the CSS clamp values that basically says at the largest breakpoint, the padding should be X size and scale down consistently until it reaches the minimum value I have set and at the smallest breakpoint I have set. Doing the math manually isn’t fun and I can be super precise now because of this function. Anyway, that’s just an example, but yeah, check it out if you ever want to make your CSS do even more!

Would love to see how this works!

I took a little detour this summer to work a corporate job. Took me 3 months to realize I didn’t want to be miserable doing work I didn’t enjoy. I’m back and trying to get up to speed with all my agency work which, before the corporate gig, I was starting to dive deeper into development. I think I’ll bump SCSS up my to-do list now. I have seen some videos, and have a basic idea of how it works.

Those variables are created from a SCSS function that calculates the CSS clamp values that basically says at the largest breakpoint, the padding should be X size and scale down consistently until it reaches the minimum value I have set and at the smallest breakpoint I have set.

My code does this now, which is cool. I don’t have to do the math myself. Would love to see how SCSS does it as well. See mine below:

:root {
	--rem-val: 16;

:root {
	--Spacing-Section: 3.5rem;
	--Spacing-XLarge: 2.625rem;
	--Spacing-Large: 2.125rem;
	--Spacing-Medium: 1.375rem;
	--Spacing-Small: 0.8rem;
	--Spacing-XSmall: 0.4rem;

@media screen and (min-width:480px) {
	:root {
		--Spacing-Section: calc(3.5rem + ((100vw - 480px)/(1600 - 480)) * ((6 - 3.5) * var(--rem-val)));
		--Spacing-XLarge: calc(2.625rem + ((100vw - 480px)/(1600 - 480)) * ((4 - 2.625) * var(--rem-val)));
		--Spacing-Large: calc(2.125rem + ((100vw - 480px)/(1600 - 480)) * ((3 - 2.125) * var(--rem-val)));
		--Spacing-Medium: calc(1.375rem + ((100vw - 480px)/(1600 - 480)) * ((2 - 1.375) * var(--rem-val)));
		--Spacing-Small: calc(0.8rem + ((100vw - 480px)/(1600 - 480)) * ((1 - 0.8) * var(--rem-val)));
		--Spacing-XSmall: calc(0.4rem + ((100vw - 480px)/(1600 - 480)) * ((0.5 - 0.4) * var(--rem-val)));

@media screen and (min-width:1600px) {
	:root {
		--Spacing-Section: 6rem;
		--Spacing-XLarge: 4rem;
		--Spacing-Large: 3rem;
		--Spacing-Medium: 2rem;
		--Spacing-Small: 1rem;
		--Spacing-XSmall: 0.5rem;

These are my variable units that I use throughout.
Top set of values is the smallest sizes for each variable. Bottom set of values is the largest.
The middle block is the calculations for viewport sizes in between.

I use them for sizing all manner of things: padding, margins, gaps. Sometimes even objects (depending on what it is).

So, for example, --Spacing-Section scales from 6rem (96px) on a large desktop, down to 3.5rem (56px) on a mobile screen.

I also get creative if I need something more, or less. I can use calc. So if I needed a spacing that was between say XLarge and Section, I could do a value like:

padding: calc(1.5 * var(--Spacing-Large))

I never have to think about what specific values a thing needs to be, because this changes so much from device to device. So, we have variable units (rem), working with variable sizing, which really supercharges the whole thing.

There’s a similar set of calculations for fonts as well.

1 Like

Here’s the SCSS function. I found the basic functionality online and modified it to suit my needs.

I added notes in the comments so I don’t forget how to use it over time :sweat_smile: but it’s pretty simple. By default, I already added my SCSS variables for the smallest (480) and largest (1280) breakpoints, which will always be the same for me. You can obviously change them to whatever you prefer. Then when you call the function, you just have to input the smallest value and largest value you want (see usage in the comments).

// SCSS global variables should be located above the functions and mixins.
// These are very specific variables, but usually you want them to be more generic
// like $breakpoint--sm or something, where the values can be changed and still make sense.

$size--480: 48rem;
$size--1280: 128rem;

// Fluid Size
// —
// Usage: fluid(1.6rem, 1.8rem, 48rem, 128rem)
// @param: $_size-at-min-width // Minimum Size
// @param: $_size-at-max-width // Maximum Size
// @param: $_min-width // Minimum Breakpoint
// @param: $_max-width // Maximum Breakpoint
@function fluid($_size-at-min-width,
    $_min-width: $size--480,
    $_max-width: $size--1280) {
    $_slope: ($_size-at-max-width - $_size-at-min-width) / ($_max-width - $_min-width);
    $_y-axis-intersection: -1 * $_min-width * $_slope +$_size-at-min-width;
    $_fluid: clamp(#{$_size-at-min-width},
        #{$_y-axis-intersection} + #{$_slope} * 100vw,

    @return $_fluid;

For example, I use the default font-size of 62.5% so all of my REM values are easier to visualize, so here are some sample usages:

// Create a custom variable that includes the CSS clamp function.
// You can input custom SCSS variables you may already have like $size--24 or straight values like 2.4rem.
// For some reason, SCSS doesn't let you use CSS variables though.
:root {
    --example: #{fluid(2.4rem, 4.8rem)};
    --example-with-custom-breakpoints: #{fluid(2.4rem, 4.8rem, 64rem, 96rem)};

// If you're not calling the function as a CSS variable, you don't have to wrap it in #{}
// You can simply call it like this:
.example-class {
    padding: fluid(2.4rem, 4.8rem);

// Which compiles into regular CSS as:
:root {
    --example: clamp(2.4rem, 0.96rem + 0.03 * 100vw, 4.8rem);
    --example-with-custom-breakpoints: clamp(2.4rem, -2.4rem + 0.075 * 100vw, 4.8rem);

.example-class {
    padding: clamp(2.4rem, 0.96rem + 0.03 * 100vw, 4.8rem);

// So when you call these variables somewhere else, you just use something like:
.example {
    padding: var(--example);

.example-with-custom-breakpoints {
    font-size: var(--example-with-custom-breakpoints);

// Or simply like we did earlier:
.example-class {
    padding: fluid(2.4rem, 4.8rem);

Haha, that’s a lot to take in, but I hope this makes sense. It’s really powerful and a massive timesaver in the long run. Also, you’ll notice there are SCSS variables used inside the function that are specific for the function only, so a good practice is to distinguish those variables from the global ones. I add an underscore before them, so I know which ones belong in the function exclusively and which don’t. For example, $random-variable is a global variable that can be used anywhere and $_specific-variable is specific to the function. It’s an easy way to keep your eyes from getting crossed when trying to figure things out!

Yep, this is the same basic idea, just different methods! SCSS is not necessary, but can be helpful in certain ways for sure. The main thing is having a system that works for you and helps speed things up. In the old days, we would have months to complete projects, then a few years ago, we might have only had a few weeks. These days, clients want things faster and cheaper, so sometimes I’m having to build entire websites in 2 weeks or less, so anything I can do to speed things up, while still maintaining some system of consistency and quality, helps a lot.

I’ve been doing this kind of thing for most of my career (since 1997… haha, I’m old!), so I can’t imagine doing anything else. I’m in a similar boat as you, though, where I mostly work for agencies (not corporate) but want to make the shift into doing it under my own business instead of someone elses. Hopefully that becomes a reality in 2023!

That’s lots of years in the biz. I’m only 3-4 years in, so lots to learn still.
I won’t clog up the discussion (since this was a bug report) any more, but it was a nice lil chat.

I think this wasn’t a bug report @owynter, even though the title and category do suggest/claim it.

Maybe @sunny wants to change the title to something more appropriate which matches the content of the original post - and the category to feedback or general, so this interesting exchange can continue.

Thanks for all the input so far, guys.

Moving this to General as this is more of a discussion on the specifics of how Cwicly’s section block is built.

Currently, we don’t have plans to change its logic/functionality as it is built for general needs.
If more specificity is needed, users can create their own sections → default classes/user defined blocks might be the way to go here.

@Louis The more I think about it, the more I agree with that, and it’s easy enough to create our own structure when needed.


Hi all,

I don’t want to start debating the section thing again, but here are my two cents on some possible compromise.

Instead of changing current section logic, why not adding a new Cwicly advanced section block OR a simple shortcut in editor UI which would insert the two nested divs with section tag and classes?

Other thought, maybe add a global setting that would change the section block’s behaviour to insert the two divs instead?

I actually don’t understand how it would hurt to have this in addition to default section block.

It’s not a big deal to create a reusable block, but we have to do it on all fresh installs, then insert and convert to normal blocks each time, and we can’t add it to quick inserter bar. I guess a single click would help me a lot :wink:

The other option is to use a block pattern, so you don’t have to convert to normal every time. If you clear out the patterns and categories you don’t want to see from the pattern selector, this can be much easier.