What's happening to the formatting of the button?

Hey @TEMPEST_114,

Sorry for the confusion here, there are a few things going on which I will try and explain.

Loss of Glossy Effect
What you are seeing here is the Bootstrap accessibility style remove the box shadow (which is used by Blocs to create the glossy effect).

Loss of Colour
The background colour is also being removed when the button is focused, this is because the global colour classes created for buttons (when the colour is assigned in the sidebar inspector) do not include a colour value for the focus state. Previously the workaround for this was to use a custom class assigned to the button, then apply the background colour in the focus state of the class (as mentioned by other helpful forum members :raising_hands:).

Hopefully that all makes sense :smiley:

The Fixes
I have fixed both points mentioned above, so the glossy effect and the background colour will no longer be lost when a button is in a focused state. This means, custom classes will no longer be required to get around this oversight.

Fixed Button Focus State

As well as this, I have ensured that the built in Blocs accessibility enhancements also play nice with button styles. You can see in the example below, the button is highlighted for accessibility and also retains its style.

Fixed Button Focus State - Accessibility

These fixes will be included in Blocs 6.3.1 beta build 3, which will be available later today.

Again sorry for the confusion and hopefully this will address the issues for you.

6 Likes

Thank you so much. I’m really looking forward to 6.3.1!

2 Likes

No problemo, the new beta is available to try here.

3 Likes

Here’s the new video showing the problem/bug in Beta 6.3.1

I’ve made another video. I’ll upload to youtube.

In the video, when I hover, it changes colour to the :hover state - all good.

When I click it the modal appears, and the button remains in the hovered state. Then as my mouse moves out of the button’s area the button goes back to it’s ‘normal’ state appearance - not focused, not active, but NORMAL.

Yet when the modal vanishes, the button changes from normal state to the ‘FOCUSED’ state, but this is also incorrect behaviour no? Because it was clicked = which showed the modal = when the modal is dismissed, but button should return to it’s ‘normal’ state ready to be clicked or hovered over again, not into a ‘focused’ state.

As the state changes to ‘normal’ when the mouse pointer leaves the button area when the modal is on screen I’d argue that this is correct behaviour and not a bug, yet when the button changes from normal state to focused state only when the modal is dismissed, I believe that this IS a bug.

I could be wrong but I’d argue that focus doesn’t make sense when showing a modal as the focus of the button from clicked state to the modal appearing and taking precedence means there is no point in the button having ‘focus’. And when the modal is dismissed then the button should always revert to ‘normal’ state and not be in another other state, so that it’s ready to be hovered or clicked again.

I have watched your video, thanks for taking the time to record that.

Regrading W3C / ARIA guidance this is taken from the following guidance. I’ve highlighted the relevant part.

It’s my understanding that this is actually a feature of the Bootstrap framework (which Blocs uses to create websites). So I would rule out a bug, I actually think it’s an intended feature.

There are a few discussions regrading it on GitHub, here is one example.

From the perspective of someone using your website, who requires these accessibility features. If they close the modal accidentally, how do they open it again? Ensuring the previous trigger element regains focus is a clear way to help a user with accessibility requirements know which part of the interface is focused and be able to reopen the modal without becoming lost on the page.

I hope that helps.

Hi Norm.

Thanks for taking the time to look into this, but even if the ‘focus’ is to remain on the button, it’s still broken because the button can’t be clicked (to re trigger the modal) until you’ve clicked off of it onto the background.

From a ui/ux perspective (my trained profession [games & apps]) this is still broken and faulty ‘logic’. Buttons don’t have a ‘focus’, especially not on websites, they have not clicked and not hovered, hovered and clicked.

I’ve got a working hack - I’m using your custom interactions to a) trigger the modal on click and b) click the background of the bloc so that the focus stays with the modal and the button works correctly when the modal is dismissed. But I still say it’s not correct as the button is still responding to hover events when the modal is displayed.

1 Like

Interesting, that is not what I am seeing when I create a button that triggers a modal. In the example below (before the gif loops) I click the button twice to show the modal trigger button functions after its been closed once.

CleanShot 2025-12-03 at 10.42.48

Which web browser did you get this behaviour?

Click twice on the button? I haven’t tried, but surely that’s incorrect behaviour too?

As for the browser, both Safari and Chrome.

Sorry, I mean:

  1. Click on the button
  2. Close the modal
  3. Click on the button (after a modal has been closed) and it works.

So in the gif I click on the button to open the modal twice not a double click.

Pretty Cool website! :smiley:
IMO, The Apple’s Liquid Glass effect on the buttons would make the website pop.

Also @PeteSharp has put together a really helpful tutorial on button effects.

That’s definitely not aimed at me right? lol