Containers strangeness

[yankiara]

Bricks Version: 1.4beta

Hi @thomas and @timmse and all,

Sorry to interrupt again but IMHO there’s still something wrong with new container and content settings and behaviour.
(Or maybe we simply need more use cases and examples…)

First issue: root vs root+inner

Imagine I set some root container padding in theme settings, to prevent content from touching the edges of the screen (I guess a lot of people do this).

Then on all the website I’ll have to use either:

• only root container (no inner container)
• only root container and inner container

Because if I use BOTH solutions, content will not be correctly aligned between simple root containers and double containers (root+inner) because of the padding:

And I can’t set horizontal padding to zero for single root container, since for smaller screens, content will reach the edges:

So why not force people to use always root+inner, which is the more flexible anyway (since you can add section background later on without refactoring your sections) and set root container default width to 100% and root > inner to some defaut content width with a theme setting? (A bit like Oxygen.)

It would be easier to set for users (less clicks, no manual settings), things would be more consistent on the website and for a dev team, on all websites!

Second issue: content width

It seems content width setting overrides root containers width, so we can’t use sections background anylonger with custom content width.

#brx-content > * {
  width: 1400px;
}

So we need to manually stretch root containers if we need backgrounds.

But then, content width doesn’t apply to inner container so it break alignment again:

So, what is the real actual use of content width?

If the purpose is real content width, it shouldn’t apply to root container but only inner containers, and if the purpose is to box all content, it should apply to root container as well.
In both cases, everything would be aligned and consistent.

Third issue: the missing simple div element

I can understand the “container” thing and I find it very flexible in theory, but it assumes it is used for section layout only.

And now we miss the most basic HTML element with no default width: the simple div.

I use it a lot to group elements like icon+text or horizontal buttons, to box things in a template, and surely a lot of other use cases.

But we need a container element with no 100% or other default width, just a container, like a div.

Conclusion

So my understanding of all this is that if you want a single container element that will be used BOTH for simple container (div) or more complex container like section (root+inner), I guess it will need some default settings adjustments like:

• default width auto when not root or inner (used as a generic div)
• default width 100% or theme setting content width when inner (used as section inner)
• default width 100% for root (used as section root)

Then with section as root+inner, root padding will never interfere with content alignment, content will never reach the edges (thanks to root padding), and we won’t have to manually set auto width for the div use.

But it will still be limitating since we won’t be able to use a simple div at rool level for layout purpose like main+sidebar or horizontal content, or box nested sections (root+inner) because they won’t have the root class, so I would be in favor of an actual new simple div element to complement containers.

Thanks for reading and for your understanding, because I know all this is biased by my personal use of sections/divs/content/width…

[ainom]

This is a great post, and related to my post here, where I demonstrated that when using the standard wrapper section/inner div structure, the current scheme is completely unintuitive because it’s backwards (even though @timmse claims it’s not…but it is, as I demonstrated). Luckily, it’s easy enough to override the built-in screwy backwards behaviour if you know what you’re doing, but I feel sorry for the folks who don’t and just want it to work.

100% agree that a simple DIV element, with no width or max-width settings is required.

[thomas]

@yankiara Great points as usual Let me address them one-by-one:

1. Root container padding in 1.4 stable will target direct child container of .root.stretch , too (as the container width already does).
2. The “Content > Width” setting is somewhat of a leftover of pre-container days where it was used to target the content on non-Bricks-rendered pages. Now that we have .brx-container.root classes on all those PHP files, we can remove this theme style setting in 1.4 stable
3. Yep, that’s the idea of the universal container element. But I can see the appeal of a simply div element without any fancy controls and CSS presets (as the container has them). We’ll internally explore a possible solution first. Definitely nothing we can squeeze into 1.4.

[yankiara]

@thomas Transferring properties from root to direct children sounds great

No hurry for the div element since we can “auto-width” and “0-padding” containers, but maybe some shortcut button to reset these properties? Like a “simple div” button or “raw” button in main tab?

[yankiara]

1.4RC ALERT!

Padding is correctly copied from .root.stretch to inner container but it is not removed from .root.stretch, so we have now both paddings adding up

[Bfrye26]

Well that is good to note. I was coming to mention this also, so glad you already have this up on the forum.

[thomas]

Confirmed! We’ll make sure not to apply the container root padding to the stretched container via .brx-container.root:not(.stretch)

[yankiara]

Hey @thomas, even if the container mechanism makes more and more sense to me, I’m still facing difficulties with this root/stretch system…

For instance, when I set a “page-header” class with custom paddings on a stretched section, this custom padding is not transferred to inner container.
Instead, the default root padding is transferred:

And if I set a custom padding on the section ID instead of adding a class, the custom padding is set on the root container, and default root padding is still transferred to inner container.

I guess there are other subtleties:

• applying custom padding on inner container with ID or class
• having only one root container stretched and no inner container (nothing should be transferred)

So, as much as I love the container flexibility with root and inner, I hope it can handle all this

Not saying that other builders do better with dedicated section element (they are actually awful most of the time), but I think there a lot of use cases to cope with and it must be easier to have a section element with root and inner and apply everything on inner. Less complexity.

Long life to container!!!

[yankiara]

@thomas @timmse,

We still can’t alter inner container padding with classes in 1.4RC2.

[yankiara]

@thomas, in 1.4RC2, when inserting a stretched root container WITHOUT inner container, no padding is applied, is it the expected behaviour?

Because then, on mobile, elements easily reach the edges of the screen.

An easy workaround is “width: 100%” instead of stretch, but it might be less intuitive since stretch is used for sections.

Actually the whole stretch root mechanism needs to be clarified for the different uses cases, I guess

[thomas]

The generated CSS is based on the CSS selector defined on the element control. Extending this logic based on its inner elements seems overly complex.

We’ll introduce a Div element soon after 1.4 to tame some of this complexity, and separate width and layout concerns better.

We are open for any suggestions about how to best implement this new Div element. Also in regards to the entire root logic.

[yankiara]

Good to know there wil be a div soon

But the container is actually not far from being flawless… The thing is all use cases might not fit into it, but maybe they could.
I suppose this is why Oxygen has a dedicated section element (equivalent of your root/inner but both are unsplitable), and a div element which acts as a your container (alone). It simplifies everything by dissociating the two container roles.
(Too bad the section element is so totally bugged .)

IMHO, a div or simple container element must stay as neutral as possible, I mean no CSS at all.
Except some min width/height if empty in the builder, so that we can at least select it in the canvas
As for the controls, all settings or CSS properties should be available, like tag choice, flex stuff, WP query, etc.

It is basically a diminished Bricks container, like with NO DEFAULT CSS and NO ROOT mechanism.

Sooo, maybe instead of introducing a div, the container element could be refined and act as div when needed:

• By default, a container is a simple, neutral div (no padding, no width, NO NOTHING).
• A switch in settings could make it root, triggering the root logic, WHEREVER it is located, so that we can use sections inside a div for layout purpose.
• When inserting a layout AT TOP LEVEL in structure with the little container icon in the corner, root option would be automatically activated, but could be deactivated with the switch in case it is needed (move to another location, save in template as non-section…), so that we don’t need to move all container content inside a div to do what we want.
• When inserting a layout NOT AT TOP LEVEL, just insert containers with no root setting activated, like container+child(ren) and NO CSS.
• In all cases, the switch allows to activate/deactivate root logic.
• When a container is inserted through a template element, don’t do anything and let the saved container work how it was set (root or not).

This could be less confusing for BEGINNERS who might ignore HTML/CSS because they would use either a container layout (with the icon) for sections or a simple container for a div to group things.

For more ADVANCED users, it would bring even more flexibiilty than today’s container, matching more use cases and allowing them to decide wherever and whenever they want how the container should behave.

Of course I don’t know how you can technically deal with all this, so that might be a pure dream, but this is the system which would fit most use cases I can think of.

And if not possible, then I would do like Oxygen:

• A complex container that would act as section with always root+inner (no single div possible, since the root logic is broken) and always root logic activated.
• A single div for all other use cases.

Oh, and I forgot, in all cases, it is mandatory that we can save any container/div as a template or reusable, and that once recalled by template element or directly inserted via template popup, they behave like they were saved.
(Today, template element systematically adds root to recalled container, maybe because templates are section templates.)

Good luck with all this

[Deanphillips]

GREAT Feedback! If this means we need to wait longer for 1.4 I’d be all for it

[Michael]

Hey chaps,

This thread is extensive, can someone help me clarify the outcome of 1.4 and say which of the statements are correct or not correct (1 = yes, 2 = no etc.) and any other scenarios that are worth noting:

Example:

Theme styles are set with a container gutter padding of 2.5rem on the left & right

1. If I add a root container (not stretched) this will have the 2.5rem gutter.

2. If I add a root container (stretched) this will have the 2.5rem gutter.

3. If I add a root container (not stretched) this will have the gutter and if I add an inner container the inner container will not have the 2.5rem padding

4. If I add a root container (stretched) this will have the gutter and if I add an inner container (not stretched) the inner container will not add the 2.5rem padding

5. If I add a root container (stretched) this will have the gutter and if I add an inner container (stretched) the inner container will not add the 2.5rem padding

Thanks all

Mick