You can now set the opacity value of an entire element, in addition to setting the opacity (or alpha value) of a color. This value can be set as a part of a Style, or individually on an element. A value of 100 means fully opaque and a value of 0 means fully transparent. The default for all elements is 100. This new ability gives you additional control over the look and feel of your application, and is compatible with any opacity animations you set on your element!
Yessssssss. This was on my list of features to request!
EDIT
Hey @nick.carroll, any idea why I’m not seeing this feature? I’m on the latest Bubble version. Or is it currently rolling out and just a matter of waiting?
And BOOM, there it is! It’s just what I had hoped. This will be super helpful for controlling the opacity of entire containers (including their content).
And just to clarify Nick’s “animation” reference…
He’s referring to the fact that opacity is now available as a “transition” (Appearance tab of the Property Editor). Exactly what I had envisioned. Sweet!
This is exactly why I keep advocating for tester groups and paid users to be on a different cluster.
Why the rush? Allow people to copy their apps to a test cluster. Then they can check things out. Give them 3-4 days, then roll out if things are working well.
Yeah man, I am by no means against bubble improving the platform. And I’m especially excited about them bringing the front end bits up to speed. No one rivalled them in logic building, but front end has been years behind the competition for far too long. So it’s a great thing, overall.
But rolling out these minor releases, which often breaks apps with no option for the users to roll back pending a fix, can’t be the best way to do it, can it? Especially not since they’re breaking live applications.
Why not get on the scheduled release tier then? It helps sidestep these issues a bit. Not a perfect solution but everyone with live users should be on it.
I think the scheduled release tier is a fantastic addition to the platform. But I’m also not sure that paying 350% more to have your application break at a scheduled time instead of immediately is the solution here. @troy.roberge 's suggestion would perhaps make more sense here?
But the recent “breaking” changes are not only an issue with live applications. They have implications during development as well. When something minor like an animation type breaks, as it did the other week. Do you, pending a potential fix/roll back from Bubble, stop other development work to address the issue on your end, which costs time and money in development. And with no transparency in where a submitted bug sits in the queue, you have no idea if it’s worth it, or are you better off not addressing the issue on your end. It’s difficult to know with how things currently are. At least for me.
Hey all, appreciate the suggestions and apologies for the outage yesterday. It is embarrassing to say the least and enough is enough. While we are in the process of hiring folks to own wholesale improvements to our QA / automated testing processes, I’m working with the team internally to implement new measures (ideally exactly what @troy.roberge is suggesting) on future deploys.
