You added a box-shadow to navbar in v7

[stevensacks]

This is about Bulma.

Overview of the problem

You added a box-shadow to navbar in v7.

I'm using Bulma version 7.0

Description

I've been trying to figure out where the white line underneath my navbar came from and I finally figured out that's what it was.

I looked in the docs and there were no variables to control this new box-shadow. I had to manually turn it off in my root css file.

.navbar {
    box-shadow: none !important;
}

Steps to Reproduce

See above.

Expected behavior

A heads up in the docs when you make a change like this.

Actual behavior

A white line appeared on the navbar of our site when we upgraded Bulma to v7.

[ozdemirburak]

Actually it is documented in the changelog, but I missed that too, probably a lot of people will do as well since it's at the bottom.

File sass/components/navbar.sass
Name	Value
$navbar-box-shadow-size	0 2px 0 0

[Come2Daddy]

Doesn't appear in docs.

[diomed]

this sure bugs me a lot.
don't know why it's placed there by default.

[stephenjude]

I added is-shadowless class on the nav and it solved it.

[stevensacks]

The issue is that the design of navbar changed in v7 which means existing sites which upgrade bulma have their designs changed in unpredictable ways.

I’m not saying that these types of design changes shouldn’t happen, nor am I saying that they should be turned off by default. All I’m saying is if and when a design change happens, they should be listed in the release notes one by one with instructions on how to “disable” each change, so to speak, to look like it did in the prior version, if possible.

I probably wasted 30 minutes in my already existing design trying to figure out why the white bar appeared and where it was coming from. When I finally scrolled down to the bottom of the element inspect styles panel and saw that .navbar now had a box-shadow, I went to the documentation for navbar and didn’t see any variable for said box-shadow. My first solution was the css override.

I would like to see breaking changes be more carefully handled. Not everyone using Bulma is on a greenfield project. I’ve had growing pains with upgrading Bulma before on other sites. This one was tougher because it was an undocumented change.

[fjelsted]

@stevensacks I can't help but feel that you brought this onto yourself. You upgraded without clearly reading the migration guide.

Also, Bulma is not at v7 but v0.7. I'd expect lots of breaking changes until we reach v1. I think you should be reading the migration guides more carefully going forward, for your own sake. :)

Jeremy did previously say that you should wait for v1 before using Bulma in production, but he kinda just gave in since people were impatient and used it in production anyways.

[stevensacks]

Bulma isn’t ready for use in production, except that there’s a book being advertised to me on every visit about how to build websites with it. We’ll agree to disagree on that point. 😉

As for the first two, you’re right. Truth be told, I didn’t even know about the migration guide. I’ve relied solely on the documentation. This ticket is about keeping the docs up to date when changes like this make their way into the code, but I will make sure to check the migration guide whenever I upgrade Bulma.

I use npm-check-updates daily on my projects to keep them as up-to-date as possible. When a new version of Bulma comes out, I want to take advantage of new features and bug fixes.

I didn’t expect the navbar to have a box shadow added because it’s been around for a long time and seems pretty well designed, as is, except for one thing that I have had to hack in.

The choice that child components disappear on mobile (except brand) is something that I understand why it was done, but there’s no workaround in Bulma to change that behavior in cases where you don’t want that. And considering the breakpoint is 768, which is pretty wide, the navbar components are disappearing way sooner than they should.

My fix is pretty involved. Essentially, I have dropdown menus that I want to always be present even if the width is less than 768 and I have to override a lot of the Bulma properties to enable it.

[fjelsted]

@stevensacks We don't really disagree. I said that he previously said it wasn't ready for production but he changed his stance since people use it anyways. And business-wise it is better for him to release the book now even if he does believe that Bulma isn't ready yet (without saying so). Nevertheless, we don't have v1 yet so breaking changes should be expected. :)

And the docs not being up to date is frustrating; that I'll give you. :) Hopefully it will be up-to-date soon.

Shouldn't this be closed now since the issue is resolved? The drop shadow can be removed with $navbar-box-shadow-size?

[stevensacks]

Has that been added to the navbar docs yet, or is it still just in the migration docs?

[fjelsted]

@stevensacks No, not yet I guess. :)

[stevensacks]

Once it is, then it’s resolved and we can close the ticket. 🙂

[Come2Daddy]

@stephenjude proposed a nice 'workaround' with .is-shadowless

[stevensacks]

Once it’s added to the docs, then this ticket is resolved. I made my own workaround, as well. The issue isn’t a workaround, it’s that this feature has not yet been added to the documentation.

[Come2Daddy]

We got your point, since the begining.

[atomi]

Got hit by this one.

navbar can have is-shadowless or has-shadow but default is a box-shadow: 0 2px 0 0 whitesmoke;

This doesn't make sense to me.

[Come2Daddy]

.has-shadow is a relic of previous versions.

Before you could apply shadow with .has-shadow, now shadow is applyed by default and you could remove it with .is-shadowless.

It's a breaking change that needs to be documented.

[diomed]

if this was less opinionated it would be better, but it looks like this was done mainly for the purpose of redesign of bulma.io site itself and therefore serves for sites of white background while other of us who use hero of various colors are left to fix breaking change that could have been done with something like .is-shadow or any other name. so instead of adding it, we have to take it away.
very bad choice.

[jgthms]

Sorry about this change. It is documented in the migration guide but not clearly enough. Of all of the changes that have happened for 0.7.0, this seems to be the only one causing problem.

I’ll push a fix today to make it optional.