New Responsive Engine Feature Request

Do you know how you can easily select the parent of the 100% wide element?

  1. When the child’s settings open, select its parent from the Appearance tab’s ‘Select parent/child’ dropdown.
  2. Also, if you know the parent’s name (even from the Elements tree), you can look it up from the Element selector dropdown near the Page selector.

I spend an incredible amount of time figuring out why some elements are wider than their parent… sometimes visible, sometimes cut off.
There should be some warning that points you to the setting that causes that.

Another example:

1 Like

SOLVED: When screen size is adjusted by dragging on the Responsive tab, the actual pixel width should be displayed IMHO

I added this as a feature request because of that issue you are facing.

Maybe a part of that feature request would be to ensure the default width is never wider than the container width.


It already is

1 Like

Feature Request

Provide access to the Container/Parent Width inside of our Conditionals.

As it is right now we have access to the page width in order to setup some conditionals.

As a way to make things more flexible, having access to the container/parent width inside of conditionals would be great.

In the original responsive editor, one of the pain points was around the fact that hiding rules relied on the container width, while conditionals relied on page width…in the new engine to have the choice as the developer of either the page width or the container width will open a lot more flexibility.

Also, if we could have access to the container width as a basic conditionality so we could use it in styles would make styles a lot more flexible and capable of becoming ‘responsive styles’. Understandable if this is more difficult and we would only have the option of adding the container width as an element based conditional, but would be awesome to have it as a basic conditionality for use in styles as well.


UI request for the Property Editor

In the Layout tab of the Property Editor, it would help conceptualization if the items dealing with the parent container came first as a discrete area, and then the items for the current container follow. I find the current set up burns up cycles.

[Edit] I see that the Layout tab deals with the subjects of a] the parent element, b] the current element and c] the effect on child elements. It seemes the structure of the Editor would benefit from reflecting this order.

1 Like

Feature, maybe a bug? not sure…

Need to be able to set “Tabbing order”

I built a column with inputs to a form.

Built in order:

  • name
  • pic uploader
  • description
  • price

Rearranged them on the screen to be:

  • name
  • price
  • picture
  • description

…but tabbing through them tabs in the CREATED order, NOT the vertical order in the column.

I am sure there are some advanced use cases where a “tab order” can be set that tabs you around the entire screen which would be extra sweet, but at least rearranging tab order to “top to bottom” would be helpful.

Thanks! :slight_smile:


Also, in the past you could just hide the group that you wanted to avoid. Now, even after hiding a group the element gets pasted into that group

Another request:
Switching from px to % in the width and height settings just takes the number you had before. So 280px becomes 280%. Can we just use 100% or something as a starting point?

Also, of course, copying and pasting responsive settings from one element to another (similiar to conditional formatting) would save so much time.


Yes, this would be great as the old engine also provided for this terrible situation in which tab order was not an automatic setting by Bubble based on the position of the elements.

I would think now that we have the previous next operators to rearrange things because drag and drop is no longer possible, it should be feasible for Bubble to set the tab order based on the positions.

Would also be fantastic to just have a simple input on the ‘input form element’ dialogue to set that tab orders manually.

At the moment the only solution is a plugin that does a decent job but is by no means in my experience perfect.


I am just copying the response from Bubble on this same subject that was linked to in an earlier post.

Upon further investigation, I’ve found that this is expected behavior. In the new responsive engine, we purposefully do not remove hidden elements by default as that can effect positioning of other elements within the same container. In order to replicate the “Hide” functionality of old responsive, you can instead check “Collapse when hidden” on the element you are trying to hide. This will remove it from the canvas when hidden.

Definitely a great request. Bubble can definitely do more to make it so that the default settings when switching is more in line with user expectations and also allowing the element to fit into the container.

Hi Tia

I would request that the posts on this thread be more directed toward a feature request rather than request for support on how to use the new responsive engine.

This post maybe better positioned on the original announcement post by Bubble about the new responsive engine. My goal with this thread was to make it a bit easier for those at Bubble with the task to sorting through all the messages they will be receiving to see feature requests. The announcement thread seems to be getting more posts related to feature requests, Bugs, How do I do question posts and opinion posts.


To take this one step further, it would be very helpful to be able to double click any element in the Element Tree and get the full inspector popup, and right-click to get all the same options you’d get from right clicking that same element in the main workspace.

Basically, double-clicking and right-clicking an item in the Element Tree would result in the same behavior as double or right clicking an element in the main workspace.


I’ve been doing the cut-and-paste, but it’s more difficult when you have workflows attached to an item. So then I have to “Copy with Workflows” and “Paste with Workflows,” and then go back to delete the original. It’s hacky.

Your idea of being able to move items within the Elements Tree is brilliant. I’d love that.


Thanks for putting this thread together.

Some other points:

  • can we show the current element pixel h/w, since we’re not drawing anymore we don’t really know the pixel dimensions
  • can we expand the properties available to us in the conditionals tab? I’d love to have more controls conditionally.
  • it would be great to allow plugins to load on a page without taking up space for responsiveness
  • also would be great if font size can auto scale between two endpoints
  • can we have control over whether a group allows for overflow?
  • can we control the z-axis for floating groups so that there is similar responsive behavior between those floating groups as if they were flat on the page.

Adding the current right click menu on an element to the element properties (popup) window would be great. This way the ungroup action (and all other actions) is always available, even when an element is hidden by another element. Maybe via a button in de window bar to open the menu (see mockup in picture)


Would be great to have the new responsive properties on an element as options in the Conditional tab. Forinstance when displaying a website on a small device I would like to change the Container Alignment from Left align to Centered