Thank you for your perspective, and the diagram.
I find the current implementation by Bricks of the Section, Container, Block, and Div elements clear and easy to use. Adding a “helper” submenu (an Oxygen term/approach?) appears cluttered. And hiding elements I would use regularly (Container and Block) is very poor UX. I disagree with your categorization of the current implementation as a “problem” to be “fixed”.
its a massive problem that we now see such elements like a block in bricks. especially since they were not requested anywhere. and we couldn’t even vote for and this block element showed up out of nowhere. my biggest concern is what elements are we going to see next. hopefully we will get some clarification about this soon, and see more real UX optimizations.
My understanding is that the additional Block element did not appear out of nowhere, but was created in response to discussions about the previous Div element.
where did you see that? there was nothing. or did you only hear about? i am still searching and can’t find anything on their roadmap. not to mention that gutenberg also uses the word block, which is some kind of missleading. now we got two div elements with minimal differences.
There is a long thread in Facebook in response to the 1.5 rc post by Thomas. I agree that the name of the element (block) may cause confusion. However, I find the element itself very useful. There have been a number of suggestions for a new name: such as box or column.
yes maybe, but it was already released with 1.5rc - i dont see any discussion before. and sorry i am not on fb. thats why i use this forum and the roadmap to get my infos and upvotes.
Here is one fb post from Udoro ‘Cracka’ Essien which I found interesting:
A CASE FOR THE NEW BLOCK ELEMENT: FASTER WORKFLOW
After carefully considering the decision and testing it, I believe introducing the blocks element will speed up workflow.
When divs were introduced, they were 100% width by default, opinions were divided on whether to make it auto or 100%. We asked for the option to set the default in the Theme Settings. We could have gotten that option, but I personally saw I would sometimes need div of 100% width, and sometimes need a div with auto width. Of course I could always change the settings, but introducing blocks solves this issue.
Block elements are just ordinary divs, but the type of divs you would typically use for most layout e.g. cards, multi-column layout etc., due to the default 100% width
Divs elements are still ordinary divs, but the type you’ll typically want to wrap around an image, short text, icon etc., due to the default auto width, hence it’s defualt display is set to block, which is the correct default for divs.
The section and container element continues to work as intended, so no issues here.
I think it was a good decision, because block is just a name given to a 100% div element, so it doesn’t break any fundamental html rule, neither does it add bloats. It will make things easier for those who don’t have a strong grasp of CSS layout.
hmm i am very sorry nora, this still doesnt answer my question where it was discussed pre 1.5rc. but thanks for the post i didnt request.
the thing is, i see a roadmap with 3000 upvotes on some features. but i cant see anything about a request for an extra div element beside the existing div element. sure, there always will be some voices on facebook finding something usefull. but since i am not there and relied on this forum + bricks roadmap, i am very worried now what will happen next.
I took the time to share information I found helpful which you said you did not have access to. I am saddened by your response.
Somehow I have the feeling that you still have not looked at the picture. There is nothing hidden.
But hey lets agree that we disagree Nora. That is ok.
I’d like presets made easier to access but the thing with predefined layouts is how do you define whether the parent section is full width or a contained width? A full-width section will not be used all the time, contained width sections have to be available as well with presets. Also, you can have 1/3-2/3, 1/4-3/4, 1/5-4/5, 1/6-5/6 splits etc. as well as the regular 1, 1/2s, 1/3s, 1/4s, 1/5s and 1/6s. You would have an awful lot of elements in the ‘layout helper’ to represent these.
The Block element should be retained but renamed to Column as many other page builders have column elements making moving to Bricks easier. Beginners will understand what a Column is from the name but not a DIV. Also, having Column and DIV as separate elements is ultimate flexibility, allowing you to set different theme settings for each.
For me, I’d like to see at the top of the Elements panel a Sections group instead of Layout which would have ‘Full width section’ and ‘Contained width section’ elements named like this to make it obvious what each does. When added to the page they are both empty and a layout pop-up is displayed showing the available predefined column layouts which would include ‘None’ so you could manually add columns/divs, and then various column presets (most users will add columns rather than DIVs). If you had chosen a full width section, then the contained column would also be available in the pop-up. If you wanted to add DIVs rather than columns, this could be an easy toggle switch in the pop-up. The forthcoming CSS Grid could also be added here as a toggle and various presets displayed.
The Elements panel would also have a Section Layout group under the Section group which would have ‘Contained’, Column and DIV elements along with a Presets element so you could manually add these. Clicking Presets would open the pop-up described above (if there were already columns, whatever was chosen would replace them). Again, CSS Grid could be added as an element in the future.
So:
Sections
Section Layouts
Basic Content
…
Just a slightly alternative idea.
Block element addresses those who need a div with preset styling since some want the DIV to be unstyled, so Block element is a good option for those who need it.
Hey Simon, thanks for your answer. 
There are different options.
In oxy Ninja you see the difference between full- and pagewidth in the icon and yes there are some of them. In Oxy you’re not limited to two icons for row so that worked there better out.
For Bricks that would end in a large vertical scrolling element that would maybe not perfect.
In view of the coming css grid (minus the buttons in oxyninja screen) that are definitly some elements.
Here I see three choices in the moment (and first view none of them is perfect). A second click option for the element (example: You click on 2cols 50/50, it twists and you have two choices: full or page width. That adds much complexity for the ui were I don’t know if Thomas wants this.
Second and maybe most flexible: Add a section optionin the element options (now content) that gives you the option to set the section to “full width, page width, custom”.
I think that sould work in any case but ends with “not final predefined elements”.
Third: Add the ready styled layouts to the menu. That ends as you already wrote in a vertically heavy scrolling element.
Personally I think that options add value to each other and the vertically scrolling - well, take a look to “general”. I think that’s maybe work out.
I like your idea to rename the Block into column. That’s a far more understandable and functional way and work for grid and flex.
Your other ideas sound interesting too. You’d just have to mock them up to see if they increase complexity too much or improve UX/UI.
@jornes if I understand him correct he don’t have a problem with “block” as element. Only with the naming and personally I like the “column” idea because it fits to everything. Maybe not ideal for using it for cards (from name) but it should work and it’s definitly more understandable than the non-speaking and non-functional name “block”.
I just noticed this article. This is how Thomas explained the block element.
Ah, been waiting for the write up on section/container/block and div, thanks for linking it @jornes.
I think as you can set which layout element is used to create columns in theme settings, this should hopefully satisfy everyone! Perhaps the term ‘block’ is causing an issue as Sebastian says, Wordpress has blocks but these are Bricks elements so could be confusing. Not sure how to rename it now that you can set which element is used to create columns, it certainly can’t be renamed column now!
Thomas’ write up says to click on the column layout action icon to see predefined layouts. I’m not a fan of these as I find them too small, other things can get in the way of them and there are no tooltips for new users to Bricks so it is not obvious. As Sebastian says, a better/alternative way to select presets is needed. Perhaps there should be a Columns tab in the Edit panel for the layout elements, so next to Content and Style and this could have plenty of layout options. It could also allow you to switch as Sebastian says from full-width to contained-width etc. and eventually to a css grid instead.
Just as an aside, did you know that once you have selected a preset, if you then choose another preset for the same section, the columns are appended to the previous ones rather than replacing them. I didn’t know it did this. One thing that I will raise a bug on, is that if you have a full-width section and delete its container, then display the preset column layouts, the first one says 100 but it inserts a contained column rather than a full-width column (which would be 100%). I think it needs a contained option adding to the pop-up.
“I think as you can set which layout element is used to create columns in theme settings, this should hopefully satisfy everyone!”
Where did you find that option? I only found the “converter”.
“Not sure how to rename it now that you can set which element is used to create columns, it certainly can’t be renamed column now!”
Valid argument. Damn it was so sleek on first view. 
However, reading all this brings me back to my starting point. It really wasn’t communicated well. I would really like that to be better in the future. I just assume now that this should be out quickly before the vacation.
edit
I think I know what you mean. But that creates a mess.
You mean the block / div settings in global styles correct?
There you can change the default attributs / Propertys of Block / Div and section but not what kind of element is used for structure (or I missed the configpart).
No imagine I change the div back to flex and 100% width. And try to export components to another installation that use the standard props for div and block. What will happen to this? Will the propertys be overwritten? Or the ones of the template?
Also that don’t get rid of elements I don’t want to use. I still have my didactic problem.
But maybe I am just overlooking something.
edit2
Ok got you now. It is not built in yet and the only part we can see this is in Thomas reworked article with features that are also not on any roadmap and with information that maybe would be very important before reconstructing the whole thing.
Thomas posted this in a discussion on ‘Some of the DIVS changed from display flex to block’:
Hey everyone 
I can understand the confusion the new layout elements might have caused.
I could have done a better job announcing this change before dropping the RC. And provide better documentation/explanation. The latter I hope has improved with the follow information …
I’ve rewritten the “Understanding The Layout” article in the Academy to explain the layout elements in 1.5 in more detail: Understanding The Layout – Bricks Academy
Would love to get everyones feedback on the article. Is anything in this article unclear or missing?
The upcoming 1.5 stable release video should add some more clarity as well.
P.S.: The “Insert layout” Bricks setting mentioned at the end of the article & some of the theme style settings are not included in 1.5-rc, but will in 1.5-stable.
So the setting has yet to appear and he apologies for the lack of communication.
I don’t know what would happen if you copy and paste to another installation with different settings for the block and div, but i have to admit that wouldn’t be something I would need to do.
@simon we overlapped. I also wrote something about it in the other thread. I’m slowly really annoyed that from left, right, top down constantly any information droplets come in. That makes so no fun.
In addition, the here now again features are under discussion, which are not even included in the RC.
Good that he has solutions, but here I see really as the main problem of communication and also the versioning and compliance with the roadmap.
I agree that there is confusion, especially for anyone that has worked with websites and HTML semantics. “Block” in my opinion is now reserved for Gutenberg. If a term within Bricks was needed to give special emphasis to a different/enhanced DIV… why not use the obvious and call them a “brick”. Considering they are only used by this name within this builder. Imagining trying to explain this to clients if they are editing Gutenberg blocks, and blocks in Bricks.
Just my 2 cents.
