I thought this must be an issue in my various projects so I just updated to the latest version, rebooted the computer, opened Elements and opened a new blank project.
Added a container and added text to it.
Font size is set as ‘base’ for the mobile layout. At the next screen size up I want to make the font bigger so I click on the overide button and adjust the size to ‘lg’. Nothing happens to the size of the font on screen. If I move to the next screen size up however the font is larger. If on that page I decide I want the font larger I follow the same process and get the same result, no change on the page I am working on but the change is made to those that follow.
It does the same with columns in a grid, ie it makes the changes on the next screen size up not the one I am working on and making the selection on.
I just checked 6 minutes in to the UI Intro video and I know it should not be like that. What simple thing am I missing?
I think this is a known problem and is due to having a vertical scrollbar on the edit window?
If you click on a screen size icon (e.g. MD) and then drag the edit window slightly to the right the font size will change from what you specified in SM to what you specified in MD.
Even though you click on one of the screen size icons to select the size, Elements is taking the size from the edit window width minus the width of the scroll bar and therefore using the next size down to determine the font size, if that makes sense.
It has caught me out quite a few times and is definitely not intuitive.
I assume this is on the list to fix?
Maybe @elementsbot can give us an update on this issue?
Great summary from @logrunner — and you’re absolutely right, this has caught a few users out!
This is related to how Elements calculates the active breakpoint for the canvas preview. When there’s a vertical scrollbar, the actual visible width is a bit less than the breakpoint icon you’ve selected. That means you’re sometimes seeing the styles for the next size down rather than the one you’ve picked, which makes overrides appear to “move up a step.” Dragging the window to resize (or hiding the UI panel for more width) will often make the preview “snap” to the correct breakpoint, showing your changes as expected.
What you’re experiencing is not the intended behaviour—and the Elements team is aware. It’s already on the radar to be improved for a more intuitive breakpoint/preview experience (after all, what you see should always be what you get in a true WYSIWYG editor!).
I’ll flag this thread to the team (hey @tpbradley / @dan) for visibility and to check if there’s any new info or ETA on a fix.
Pro tip:
When previewing breakpoints, make sure your edit area is wide enough for the current size plus the scrollbar—collapsing panels or dragging the window wider can help until this is fixed.
Thanks for raising it again—keeping these little quirks at the top of the list helps them get sorted faster!
Feel free to @elementsbot if you have more questions, or want to nerd out about how breakpoints work under the hood.
This should have been fixed a long time ago and I’m having trouble reproducing it here. I’m following the steps in your video, dragging on a container followed by the text, then overriding the text size on the second breakpoint.
@jbyfield Can you confirm which version of Elements you’re on, 1.0.5 is the latest. Also, can you tell me what Mac and screen you’re using?
@logrunner Can you give this a try too and let me know if you still see the problem?
Not a fix, but this issue is caused by the always visible scrollbar (not that I can reproduce it here even when I switch to always having scrollbars visible).
I’m wondering if this is related to the mouse you have connected/settings in the system. @logrunner, @jbyfield can you let us know the following:
What pointing device(s) do you have connected? Is it a non-Apple mouse with a physical scroll-wheel?
What are your settings in the System Preferences > Appearance > Show scrollbars?
