Visibility Control - Breaking Points Vanished?

What has happened to the visibility control and why have they been removed? Really need this function today and not sure of the alternative? (I want to display a number of sections on desktop only and different sections on tablet / mobile?)

@cyberdave - any ideas please?


Here is my site Read-Only: https://preview.webflow.com/preview/fountech?utm_source=fountech&preview=ef33e53e24185bcd0c2013a2d0d7feea

I assume the removal happened because it was a bit buggy from the start. To hide elements on certain breakpoints just set its parameters to display:none on the desired breakpoint.

1 Like

Hi @dram

Thanks. But how do I do this using the designer? Am I missing a trick here?

Many thanks

https://preview.webflow.com/preview/fountech?utm_source=fountech&preview=ef33e53e24185bcd0c2013a2d0d7feea

The crossed eye in this panel is a “none” setting for the display.

You can handle this using CSS. Add the attribute “display: none” to the class (or create a combo class for a specific item) to whatever breakpoints you don’t want it dhidden on. I used to use the hide feature as well but the thing was that this altered the HTML vs using CSS. This was an issue for when exporting to my developers who were really counting on the CSS to control everything.

2019-01-14_152322

Hi Dram, I understand this. However the issue I maybe having is the Page Load IX (attached) is displaying the elements on all breaking points - the visibility function resolved this (I maybe wrong).

08

Hi @Matt_g

Thanks for comment, makes sense.

However see my comment above (page load IX), could this be causing a conflict / the sections to be displayed on all break points.

Appreciate it, thanks.

Darren

1 Like

I certainly would. If the class is originally set one way (display: none) but your interaction (page load) is calling it to act a different way (display: flex) then there is your conflict. This will result in the object to be shown whenever this page load interaction is triggered. Have you considered using different interactions based on the break points?

1 Like

Well, it makes sense actually if you think about it - your interaction is making a change to the display settings. Just make a separate interaction that will only affect loading of this particular block and set it to fire on desktop only (or any other combination).

So curious if anyone can answer @thinkrandom other question which was… “what happened to the visibility control?” Is it removed permanently or did it just get moved?

@cyberdave - Can you let us know?

Thanks!

Thanks @Matt_g.

Where can I select interactions to trigger on break points?

Thanks @dram.

Interesting - where is this trigger option? So if I wanted to use a Page Load interaction, can I then chose which break point for this to trigger on? If so this will solve my initial issue I guess.

At the very bottom of the interactions settings (where you choose the interactions for your element)

Hi @path

I noticed a warning saying that this was Point o be removed and then it was unavailable.

@Matt_g makes a good point / explanation above. Ive just been caught out and not full understood the difference between the Visibility function and the display options.

1 Like

Yup, I just went through the same thing. And funny, the panel appears and is available in places I used it before the warning sigm

@Matt_g explanation helps for sure…so thanks for that!

Just wondering if I slept through the announcement “and” if it’s still there some where

Perfect! My list of interactions is now so long I cannot remember the last time I seen the bottom of this panel.

Thanks @dram, super helpful.

I have just had a support response, any elements you currently have using this function will remain until you change / remove then the warning will appear and off it goes.

This thread has been very helpful, and the update is beginning to make perfect sense.

To clarify, for those elements still using it, these visibility settings will still be accessible.

However, after you disable this setting entirely (i.e. make the element visible for all breakpoints), the next time you come to this setting in the Designer you’ll be met with a note and those settings won’t be accessible.

We chose to deprecate this setting because there were quite a few bugs associated with the visibility settings and it was a bit too abstracted away from CSS (at least more so than most Webflow style settings). It was causing quite a bit of confusion for a lot of users. After some deliberation as a team, we decided to remove these settings in favor of using display:none in the Styles Panel.

Hope this helps clears up any confusions. :slight_smile:

3 Likes

Hi @dram, @Matt_g

I have made some updates to the interactions. However, if the desktop site is loaded and I resize the browser (or chose a different break point in the preview) this element is then visible on all (the interaction loads the element on desktop breakpoint and remains visible when resizing the screen)

Any suggestions?

That’s the drawback, yes. But since most of the time your visitors will not go resizing their browsers back and forth (I think mostly us designers do that when facing some interesting looking site to see the responsiveness, haha) it shouldn’t be much of a problem. But yeah, I’d love to have some kind of reinitialization in case of breakpoints crossing on the fly.

2 Likes