WIP: Having position relative on all Bricks elements and containers adds limitation

[wplit]

Having so many levels of relative positioning prevents all types of things with absolute positioning, as elements are only going to be positioned relative to their direct parent. Unless we manually change all the higher up parent levels back to static.

Often we need to position nested elements to be positioned relative to a higher up container, like a section or a header. If there’s a way to bring ‘static’ positioning as the default, this would be ideal.

(i can see why it’s being used in the builder, for the margin/padding/action controls etc. So not an easy one to change). but I think for long term, having the UI separate to the page flow, appended to the body - and then using JS to calculate their position relative the whole page -, instead of relying on absolute positioning inside of the elements may be a better approach and would make all the relative positioning not necessary) Also would solve the problem with opacity not being able to be visible in the builder, as the UI wouldn’t inherit the opacity anyway.

edit - there’s also the additional problem of currently not being able to see absolute positioned elements in their correct position in the builder, due to the need for the relative positioning to hold the UI in place. So we have to keep checking on the front end and this means the builder isn’t going to represent the correct design. This wouldn’t be the case if the UI was separated from the elements.

[Deanphillips]

@thomas is there anyway to address this whilst also not breaking sites that have relied on this already?

[thomas]

Hey David,

Moving away from having the element actions, resizing, etc. controls inside the individual element is something I will start working on in the coming days. I will update this post as soon as I have some news.

@Deanphillips Changing the default element position to static is just one line of code in Bricks, but it might break layouts of sites that rely on the relative position, but haven’t selected it explicitly from the dropdown. We could run, of course, run this sort of logic through the new Converter

[wplit]

That’s great news. There was also an additional issue some were having trying to use :nth-child on containers, which was obviously picking up the UI elements as child elements, so this would solve all of this in one go.