Blocs for Mac V5.2 Beta Build 11 😅

Here it is, the last beta of November. This is Blocs for Mac V5.2 beta build 11 with more fixes and improvements for you wonderful people to help test.

Happy testing :raised_hands:

Download Blocs V5.2.0 beta Build 11

3 Likes

Hey @Norm

When adding children to Page Lock, it’s pushing central content below the lower divider line - shouldn’t anything added to the edit window just keep expanding the middle area?

Thanks,

Bill
BricsDesign

1 Like

Do you have any styling that would hide the overflow or alter the positioning of the Brics content?

No overflows in styling and major outer divs are display:block;position:relative I wonder if this has always been this way & I just found it, but I know I’ve added two users before in testing and it displayed as expected. There’s text not showing and version number not coming in, just bizarre stuff. Since I can’t inspect the css in edit mode, I’m blind on what is causing this stuff.

It seems the dom isn’t respecting the height of the elements - I wonder if setting a height to force center area down - I’ll try that, but that’s just a temp hack and shouldn’t be necessary.
(Update: height hack didn’t work, just forced it down & made overlap worse)

Bill
BricsDesign

I’ll take a look today.

@Norm

Also, is there a limit to the number of storeCustomBricTemplateVal ?
I tried adding one today & it doesn’t work in a regular custom bric, I think this makes 47 of them.

Bill
BricsDesign

Is the crash happening in preview mode with the inspector open?

Could you please share the project with me so I can take a look?

1 Like

Just checked this going back to Blocs V3 on running on MacOS Ventura. My guess is that something changed recently at the OS level that’s caused this.

I’ll see whats up.

I’d need to check, it could be something internal used for reference.

I’m still unable to crash Blocs using your project. Im not sure if this is consistent for you?

Regarding the font issues, it looks like you have the Worksands-regular font set on every breakpoint in the h1,h2,h3,h4,h5,h6,p,label,.btn,a.

But the form-button is only set on the LG and MD breakpoint so on the lower breakpoints, it’s using the h1,h2,h3,h4,h5,h6,p,label,.btn,a class font rule.

I discovered this by checking the classes for each breakpoint using the reorder feature.

You can also use the !important option in the class editor on your form-button class, this will force the font and also fix the issue.

Hey Bill,

I’ve looked into this and it looks like you have a Blocs container nested in some PHP code.

As PHP support for custom Brics is limited and won’t render on the Blocs design environment and is instead represented by a php snippet box (which has a set height of 40px) the html content within this php is is being displayed but its height is not part of the calculation of the overall Bric.

You will find in the next beta this overflow is now hidden which means your content area will not show at all as it will be hidden within the 40px height of the php snippet box.

My advice would be to close your php ?> before the Bric container and restart it <?php after, this would give you 2 php snippet boxes and a container between them.

I hope this is helpful and explains why you are seeing this.

That happens when the font has not be loaded by the browser. I don’t have that font so its hard to test any further, if you can generate an export with fonts and share that I can take a closer look.

Its likely something the css structuring.

1 Like

Hi @Norm

Well, I don’t know what you were looking at, but my php Does Not wrap the Bric container.
It’s basically:

<div>
<?php  ...
?>
</div>
<div>
<?php ...
?>
</div>
bric_container
(other html which is not showing for some reason)

Note: bric_container is below all the php.

Here’s what it looked like when added in beta 11:

Here’s what it looks like in beta 12:

Now, this is even worse as the grey drop zone is not shown in edit area & it appears to be outside of the bric !

The shot below is with the Div Container selected in Layer Navigator & Pg Lock-Admin hovered - Please Note: the dropzone is outside of the bric as you can also see the highlighted bottom border of the selected bric (and yes when placing any child bric it still overlaps as before):

I looked at the html generated on the canvas and it’s placed within the php once it’s rendered by Blocs. I’ll take another look and see if I can spot what’s up, it may be something to do with the php formatting.

So I am working on NavPlus, and I have a keydown event listener, only I find I get an error, because suddenly its looking for lightbox (which is not being used in the dev project) with the blocs javascript :rofl:

My code is…

 keyboardNavLink.addEventListener('keydown', (event) => {
    if (event.key === 'Enter' || event.key === ' ') {
        // doing stuff
    }
}

What’s the solution here? :man_shrugging:

I’m not sure, the blocs.js includes the event listener for keydown for navigation of light box, so there is obviously a conflict here between your code and the default Blocs code.

I may be able to adjust the event listener for light boxes, so it’s harder to conflict with from other JS.

This would need a week or so of testing, so I’ll come back to this in V5.2.1.

Is it because blocs is apply the event listener to the entire window. I’m only on particular nav items?

Edit:
I had a late night thought, I will give adding event.stopPropagation() a try tomorrow. It may need to be added to the blocs js too??

1 Like

Yeah that function captures all keyboard events. But right now it doesn’t check for light box existence, which I’ll change.

1 Like

Using event.stopPropagation(); in my event listener seems to stop the blocs.js triggering an error.

2 Likes