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.
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
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.
A thought on this is add the option to the settings that can change it. Then it can be left as ârelativeâ as not to break existing, but allow the user to pick/change it to suit their needs.
My thought really is âanythingâ that a end user could possibly want to be different from the default in terms of a variable item like this should have a setting that can be managed. Then you donât break anything existing on updates, but allow for a change and allow it to be exported into a JSON or whatever that can be imported for future sites as defaults.
The default value as per the html spec should be static - shown here - âstatic - The element is positioned according to the normal flow of the document. The top, right, bottom, left, and z-index properties have no effect. This is the default value.â
If there were to be a switch then it should be set to static as default and then be able to set to something else if the user wants. Existing sites settings could be run through a converter so as not to break sites.
You probably need to use position relative in certain situations. Like if you have an absolute positioned link as a child element that need to take up the entire space of the parent container - in this case, setting everything to static will break it and the child element will now become positioned relative to the entire page (or whichever container is set to relative) rather than the direct parent.
This is why it canât be just changed globally without many of the existing elements first being tested. Some of them will need relative, some of them wonât.
Anywhere where youâve been using position absolute, youâd need to make sure the correct container has position relative.
