Bricks Version: 1.5 Beta
Why is this styling necessary? When I add a DIV to a page, my goal is to have an unstyled container. Having default styles interferes with utility classes.
If this is required for other elements, it’s definitely not required for divs so it should be excluded from .brxe-div
Hi Kevin,
Good question. The width: 100% is added to ensure the div takes up space inside the flex section/container. Needed as those layout elements have a align-items: flex-start rule.
The other flex rules are there as display: flex is the default for the Div element as well.
Could you provide an example how exactly those CSS rules interfere with your utility classes?
When these elements have default flex styling we have to pull all our flex and display classes into a separate file and make sure it loads after Bricks in order to create overrides. For sections and containers it’s not really a huge deal because we already have to create overrides to target those. But a blank div should just be a blank div with no styling. It’s the most basic element and not being able to use classes on it out of the box adds additional layers of complexity for basically no reason.
For example, our sticky classes don’t work on divs because they can’t set the display to sticky. So now we’re faced with moving the sticky classes to the overrides file as well. We can obviously do that, but IMO there shouldn’t be a reason to.
Is there a benefit of setting a div to display flex and flex-start? By default, anything that’s put into that div will be in that exact same position anyway without the flex rules. There are so many uses for a div that it’s undesirable to have a pre-set starting point. Especially when that starting point more or less behaves like an unstyled div would, except it now has rules that need to be overwritten.
Spot on. Training wheels not needed.
I totally understand your point of view, since you want to integrate your plugin with bricks as easy as possible. But you should think the other way round too. Bricks is not only for devs and people who know HTML, CSS, JS & PHP.
And for me, personally, that’s what makes it superior over oxygen for example. I personally don’t like the idea of letting clients work inside the builder, but still this is something they want to do and I’m always happy if they break something so they pay me to fix it 
But jokes aside… i think some basic default styling (except the one with the width) are totally acceptable as they make life easier for that group of Bricks-Users who are more from a designer-background and not from a coder-background.
Those who are familiar with coding will find a way to let the elements behave like they want anyway (and specially they will know more likely which controls to change than the other group).
I like the idea that the elements cover 80% of the standard-needs by default (without changing or adding any settings) and the other 20% have to be done that way. The other way around, the 80% would have to be done manually and the 20% special cases are covered by default! I often see discussions about “1 or 2 Clicks too much…”, wouldn’t that just create the case that you often have to add settings which are now covered by default (for users who don’t use ACCS of course, because ACCS users have their utility classes anyway).
I have an example: Working with Flexbox and Flex Wrap is great for responsive development. But if all divs are 100% witdh, the moment you try to work with Flex Wrap, you will have one row per div and not the nice metro like tiles with great responsive behaviour.
divs should not be 100% width by default and should only take up as much space as is needed by their child elements imo. The first thing I do is set their width to auto in a theme style. I consider this a minor inconvenience.
Yeah but I guess this is more about the default behavior/styling than what can be done to override it.
This really has nothing to do with my plugin or framework. It’s just how things are supposed to be in general dev. There’s no benefit to these default styles being placed on this element.
Fully agree … as little default styling as possible for a pro builder!
.brx-nestable has been removed in 1.5 RC, and there is now a plain “Div” element without any default styles.
So, that is the reason for breaking the layout for Tabs (Nestable) after updating to 1.5rc… 
Just a simple fix. Can get back to how it work like the previous div.
The new block is a nice addition. 
