Hey everyone, here is Blocs for Mac V5.2.1 beta build 3, with more fixes and improvements.
Happy testing and have a great weekend 
3 Likes
I’m just trying the new bric/bloc selection in areas with low (zero) padding and there seems to be some deviation in the behaviour between top & bottom.
If I click on a bric e.g, an H2 header, +bric icons at top and bottom of the selected bric. If I then move the mouse slightly to hover at the side of the bric icon the new +bloc icon appears instead, but only at the top side of the bloc.
If I try clicking the same header bric the +bric icons appear, but then I have no option to add a new bloc underneath unless I physically click onto the bloc.
Right now I don’t know which is best, but do think the behaviour at top & bottom should be consistent.
yeah I noticed that once the beta was live. It’s typically the insert Bloc buttons at the bottom of Blocs below the selected element in a low padding Bloc. Its all very edge case stuff.
I must honestly say I’m impressed with the new Bloc/Bric toggle! 
It needs some fine-tuning on custom Brics as it seems not to work with them. But for a first beta, it’s a huge step forward. Thanks @Norm! 
2 Likes
I just tried adding a standard four card feature bloc with images. At XS they look fine in edit and preview filling the full card width, but on an actual device there is a big border either side of the images.
Notice the global zone line overlays the button for the bric, I get that too
I think the accordion aria needs addressing Norm, it doesnt look like it was ever fixed.
1 Like
I’ll get that looked at.
A live link would be great to see what is up here. My guess is the images have a fixed size.
I’ve just sent you a PM with the live link, as well as the project exported as a package. You will see this on the home page.
I just tried it in Safari on my desktop and set the user agent to iOS 17 iPhone. There you can see how it is fine at LG and MD, but as you narrow the browser the border appears either side. It’s actually there at SM as well, so visible when the iPhone is landscape.
1 Like
Hi Norm, et al.,
I ran into a problem using the beta Blocs loads (5.2.1 b1, 2, 3) with some of my projects in viewing via the layer tree any content blocs I have carousel brics in. There was no problem viewing these content blocs with carousels using the official 5.2.0.
I sent the detailed problem description using the official bug report tool, but wanted to mention here in case anyone else is having a similar problem.
Thx.
pruthe
1 Like
I was just working on a logo image for a client and wanted to see how it looked at a large size on a web page inside Blocs, so I set the magnification to 150% and found that the page basically rolls over the entire interface, so you lose the ability to flick back into edit mode, change the magnification or anything else. It’s messed up.
Eventually by clicking along the top of the preview image I found the magnification option on the right through a process of elimination and set it to 50%, which restored the user interface. If it makes any difference the image was an SVG.
1 Like
If I understand the issue correctly, there are two other ways to get out of this.
- Grab one of the edges (left or right) and move it. It’ll suddenly show the tool bar.
- Go to the main menu> Window > Window Frame Size (doesn’t matter which one) and the UI will be shown.
@Flashman, maybe nothing to do with your problem, but a few months ago I used an SVG file as a logo in the menu and at random points it would suddenly become huge and lock everything up. Only mentioning this as I had a few svg problems.
Once changed to png (same dimensions as SVG), all was fine, so maybe Blocs has an underlying problem with svg’s, don’t know, although I’ve also used them a few times with no problems.
Maybe but I would prefer the option that it is fixed, because this is something that just shouldn’t happen. Having the preview cover the interface so you have to hunt around for options just to enter edit mode is clearly not right.
I’m not in front of the computer right now but I don’t think it was even possible to scroll the preview. I will check later.
1 Like
@TrevReav I’ve had that before as well and from memory it was caused by a bug involving the order of custom classes that should have been patched. In this case the SVG does not become huge.
Setting the magnifier to 110% or higher simply loses all interface options and I’ve just confirmed that using a Jpg image. In this latter case it also led to cropping the Jpg image, because it didn’t have a large border background.
1 Like
I’ll check this could be an bounds issue with Sonoma, lots of changes to how views are cropped in that version. Likely the overflow is not being masked out.
I’ve taken a look at your project (thanks for sending that). Rather than send a direct message response, I thought I’d post here incase it helps others who may run into the same issue.
The issue is caused by the image size tag automated feature in Blocs, which you can disable, but is recommended for better Google page speed scores.
Basically the image has a max width of 265 which is applied by the automation feature I mention above. When you go to a lower breakpoint the layout reflows, giving the image more space, however the image will not fill the bigger space as it’s width tag is 265.
There is a scale option (in the image settings in the sidebar inspector) that can be enabled to address this type of layout issue.
Selecting the proportionally scale up and down option will allow the image to scale up and down based on available space, rather than only down from 265.
The image is 600px wide. Why would it have a maximum width of 265px? There should be more than enough to fill the card at any breakpoint.
I hear you. I only pointed this out for anyone that found themselves in this situation, but I agree this shouldn’t be so. Perhaps @Norm will correct this on the next build.