Hidden Element causes misalignment of other element(s)

[laurence]

Edit 5/6/19 3:35pm PDT:

As Petter and Duke point out, this is not a bug. However, if you encounter alignment/responsiveness problems, this may help, especially when you come to Petter and Duke’s explanations and tips.

---

Original post and identification of solution:

I don’t know if this is considered a bug, but it is extremely odd behavior. Because it is so odd and the cause is by definition invisible, it can eat up a lot of time to resolve if you encounter it.

Here’s my simple scenario:

Responsive page with preset page width: Centered.

One hidden reusable workflow element, i.e. the reusable element is hidden on the page, contains no other elements and exists solely to contain workflows to be used on any page where the element is placed.
The hidden element is its default size of 5X5. It is placed at 0-0 on the page. It touches no other element on the page.

The only other element on the page is a group of fixed width, 20 pixels narrower than the page, It is centered, i.e. 10 pixels from both left and right edges of the page. As a result, it does not touch and does not overlap the invisible element.

Examined in responsive mode, it is clearly intended to be centered.

Nevertheless, the group is pushed to right.

When the hidden element is placed in the upper right corner, again, not touching the large group element, the group element is pushed to the left.

When the hidden element is placed fully underneath the group element, the group is centered as it should be.

So what’s up with this? Is it a bug or is it an oddity that should be clearly documented?

[andrewgassen]

What happens if you make the 5x5 element fixed width? I notice it’s unchecked in the screenshot. Not sure if it’ll matter, but just spitballing ideas.

[laurence]

That doesn’t quite fix things.

When set to fixed width, placed at 0-0, it pulls the large group toward it. The left margin is about 50% of the right margin.

When placed in the upper right corner, it locks the large group on the right.

Oh, and again, when at 0-0, it causes the large group to drop down when the page gets too narrow.

FUN! not

Does anyone know what the rules really are?

[laurence]

I have one bit of good news, if you can call it good.

The problem is repeatable. I duplicated it in another app, building a new page from scratch.

[petter]

Hi @laurence,

The responsive engine can be a bit tricky to wrap your mind around, but once the logic falls into place it’s a lot easier to plan for the site. In this case, there are two words in particular that are affecting the behavior: margins and rows.

That may seem obvious, but let me explain with the examples you gave:

When set to fixed width, placed at 0-0, it pulls the large group toward it. The left margin is about 50% of the right margin.

In this case, the margin is the keyword. You are thinking that the centered element has a margin of 10 pixels on both side, as that’s the distance to the page edge. But here’s the thing: Bubble calculates margins not from the page edge, but from the elements next to it. As your hidden element is 5 pixels wide and the centered elemet is placed at 10 pixels, its left margin is actually 5 pixels, not 10. As the page width increases, the margins grow percentually, and the wider it becomes, the more visible that difference becomes (and your 50% guess becomes accurate!).

Oh, and again, when at 0-0, it causes the large group to drop down when the page gets too narrow.

This is where rows come in. Two elements are considered to be on the same row, if at least one of their pixels is on the same Y coordinate. In your example, they match up perfectly, as they both share the same Y coordinate of 0. Both your elements are fixed width, which means Bubble is not allowed to squeeze any of them to make room when the space gets narrow, and you’ve also told Bubble that you want to maintain the margin on both sides of your centered element, which means it cannot squeeze them either: there’s nothing else to do but to move it down a row.

I set up a quick example to show what I mean. Note the pixels/percentages on the left side and how the “row dumping” occurs at 980px, 100% width:

How to solve it
As always, there are numerous ways, but an easy one is to simply place the hidden element on top of the centered element instead of next to it, set it to not be visible on page load and collapse its height. That way, the user won’t know it’s there, and it will not disturb any other elements.

[laurence]

Thank you, Petter!

That all makes perfect sense. I just don’t know that stuff because I’m not a web developer - I’m an old mainframe -> mini -> msDos -> Windows developer.

The basic idea I came to was along the lines of your solution. What worked was to put the hidden element under the large group. I think the results would be the same but I suspect your approach would reduce the likelihood of future problems because the hidden element would be contained. When it’s under the large group, it could inadvertently be exposed with future page mods and cause unexpected problems.

I guess the most frustrating thing about this is that, as with a lot of Bubble behaviors, if there is any bit of clear documentation, it’s devilishly difficult to find. And there’s a lot about Bubble development that simply assumes a certain level of understanding of web technology (HTML, Java, et al) even though an app can be built without actually writing code.

I appreciate your clear explanation!

[duke.severn]

Just my two cents, because I’ve been playing around with this for a while now. This is not a bug and is “expected behavior” in the bubble rendering engine. The way it works is that if an element is rendered (whether visible or not), bubble creates a pseudo-element (bubble r-line or r-box in their nomenclature) and uses it to paint a margin. If your element is invisible, but is required in your workflows (states or “displayed data”), it will render and so will the r-line and r-box, which is giving you that nasty behavior.

How to solve it (II)

Airdev suggested putting all of your pseudo-elements (things you don’t need to display but need to render for data-manipulation purposes, states, etc…) in a popup. That way you can have access to them and their data/states but they will not affect the rendering of your actual display elements.

[laurence]

Airdev suggested putting all of your pseudo-elements (things you don’t need to display but need to render for data-manipulation purposes, states, etc…) in a popup. That way you can have access to them and their data/states but they will not affect the rendering of your actual display elements.

I like that! I’ll have to go back an look for the Airdev documentation on this. I’d seen something Vladimir had posted a month or more ago.

[duke.severn]

Don’t know if there is documentation. I just read someone else posting about it here on the forum and giving Airdev the credit, so I thought I’d pass it on here.

[petter]

It’s all a matter of preferences, but generally I like to keep my groups stacked like a game of Tetris to 1) collapse them when not needed 2) have them orderly listed in Element Tree (which sorts by Y position on page). I tend to build my apps mobile first, meaning I design the app in about 300 px minimum width and then allow it to stretch. As such, that solution makes perfect sense to me, as elements that are next to each other on a desktop screen are actually placed underneath each other, and then moved up with the Wrap to previous line if the page is stretched setting. That gives me the highest amount of control over responsiveness, in my view. Not everyone prefers the mobile-first approach though. I can think of numerous power-users whose work I admire on this forum who prefer building a desktop-first design with excellent results.

The suggestion @duke.severn made about popups is one I haven’t thought of, just proving again that there are many ways to reach the same goal.

I struggled a lot with the responsive engine until I actually spent a few hours simply placing groups on a page, giving them bright, highly visible colors (like in my gif example) and simply played around with the responsive settings and try to predict how they would behave as I changed the page width.

I agree that Bubble’s documentation is not perfect, but I think (and also agree) that as a small company, it’s an essential part of their strategy to outsource a big part of the learning resources to third parties orbiting their platform, in the form of written/video tutorials, templates, this forum, etc. And while that may lead to some searching and sometimes frustration, it does leave the Bubble team focused on developing the product, instead of spending a big chunk of their resources maintaining documentation and answering questions. I even think their lack of response when people tag them on this forum (which is probably hundreds of times per month) is a deliberate choice to stimulate the community to produce answers. In the case they do respond it’s often related to discussions where the general interest is very high, or where the community can’t really know the answer for sure (such as questions related to the performance and security of Bubble’s engine).

[laurence]

Petter,

I agree with what you say, and I’m not griping (usually), I’m just observing. I understand Bubble’s need to focus its resources, and a lot of great support has come from the community.

One thing I’ve observed in the past 19 months, since joining the community, is that forum content has gotten harder to navigate, and a lot of time can be spent reading many long threads before finding a solution. But that’s just the nature of things.

I genuinely appreciate all the help I’ve received from you and others in the community.

Cheers!