Hello,
I am hoping to add more fine tuning to my responsive design. I have a header and would like to reduce the number of elements displayed in the header as the users’ viewport width decreases. I was able to do that easily with the big breakpoints of tablet and mobile, thanks to WeWeb’s built in tools. Now, I’d like it to be more of a continuous change as the size changes.
I recorded a Loom to illustrate this a little more clearly: Loom | Free Screen & Video Recording Software
Thanks!
Is there a way to dynamically determine if an element should be displayed based on window width?
I know that there are the desktop-table-phone breakpoints, but is there anything that would allow the change to be smooth as someone expands or reduces window size? @Joyce @weweb-team
Hi @kyanaloe 
Not with no-code, no.
This is an edge case that very rarely happens in the real world (users don’t tend to resize their browser windows).
May I ask if there’s something about your use case that leads you to believe users are more likely than average to resize their browser window?
I don’t know if it is very unique to my users, but they may want to look at a document or other file while working in my app, so they may want to make the app smaller on their screen so they can have multiple windows open - especially if they don’t have access to multiple monitors.
Mostly, I have one element in the header that ends up on the page itself in between the tablet and desktop width. I’d really like to clean that up. I’ll see if I can figure out how to do it with code.
Thanks for getting back to me
Oooh, super interesting use case!
I’ll investigate more with the team to see if we can find a solution for you.
If the goal is hiding an element at a specific screen width can we just use a media query in a custom css? Someting like @media (max-width: 456px){ .hide-me{display: none !important;}} . It is ugly that !important is required to override the specificity though.
Would this interfere with weweb or can it be used as a workaround?
Hmmmm, I’ve tried to use this approach but might be doing something wrong.
I want to show/hide elements at a 600px breakpoint. Element 1 = display:none on desktop, and element 2 = display:flex on desktop. There are no changes to the display at different breakpoints. I have given element 1 the class display-on, and element 2 has the class display-off.
The custom code for the app is:
<style>
@media (max-width: 600px){;
.display-off{display: none !important;}
}
@media (max-width: 600px){;
.display-on{display: flex !important;}
}
</style>
Any tips for what I may be doing wrong? Thanks in advance 
max-width media rule applies to screen soze minor or equal than the specified value. If you want the rule to be applied to screens larger than 600px you need min-width
Thanks @dorilama. I could be missing something here, but for screen sizes larger than 600px the existing display settings are already correct - I don’t need these media queries to activate because element 1 is already hidden, and element 2 is already displayed. The intention was activate this media query as an override for the display on smaller screens (<600px), where element 1 would switch from none to flex and element 2 would switch from flex to none
I prefer to have a single place where things are handled. If you manage the display with custom code do it there for every condition of that element otherwise it gets more tricky to debug.
also custom css will work in the editor only if inside an html element, global code of the page works only in the published app, maybe this is the problem here
Wouldn’t the pageSize variable help?
If you bind a formula like Screen.pageSize > 1400 to the Display property or the conditional rendering
You could even create a variable to hold those intermediate breakpoints for better maintainability.
@dorilama thank you for your guidance. I tried setting a min-width with opposite display properties in the custom code and that didn’t work either. I was testing after deploying as I knew about this limitation as well. So not sure why this didn’t work, but…
@jptrinh I hadn’t realised we had this variable to use. This is exactly what I was after and it means I can avoid custom CSS. It works perfectly - thank you very much!
