MsDestiny… new BJS helper… cooooool… welcome.
Probably, line 1 of that playground should not have engine in it.
More correct method… var createScene = function () {
Removing the engine from line #1… allows us to use the engine variable name… later in the code… like https://www.babylonjs-playground.com/#L76FB1#152 line 108.
Also note… there were TWO background, color, and cornerRadius settings in the button for playground #150. All these mistakes were OLD mistakes, and NOT created by @msDestiny14.
Now, let’s look MORE at playground #152 (myself and @msDestiny14 are going to have a canvas resizing pow-wow, here). #152 is preparing for canvas resizing… both vertical and horizontal. (I added another button on the left side, vertically-centered.)
There is also a canvas resize observer… active in lines 108-110. Not important at this time.
@msDestiny14 - notice that I changed the value of button1.top (I made it a negative number - line 78) and I also added button1.verticalAlignment = BABYLON.GUI.Control.VERTICAL_ALIGNMENT_BOTTOM; at line 79.
Now let’s open our F12 dev tools (in desktop browser)… which causes a VERTICAL canvas resize (and you can drag the divider line up/down to do MORE vertical resizings). Notice that the bottom button moves up/down… when the JS console is opened/height-dragged? No blocked buttons. In PG version 152… opening the dev tools (F12) made the lower button disappear. (the button did not survive canvas vertical resize). But now, in PG #152, the button stays in view. This is because we used button1.verticalAlignment = BABYLON.GUI.Control.VERTICAL_ALIGNMENT_BOTTOM;.
Same for horizontal resize of canvas, and button 2. Line 95… button2.horizontalAlignment = BABYLON.GUI.Control.HORIZONTAL_ALIGNMENT_LEFT;. We can drag the divider bar between the playground canvas area and editor area (resize the canvas horizontally)… and the left button automatically moves DURING the resizing. We can drag the playground’s vertical divider left/right all we wish, and the button TRIES to stay in view.
PG #152 also seems to act ok during control-mousewheel actions.
I don’t know if @saifshk17 will be asking about canvas resizing later, or not. Maybe. But if a GUI scene can survive control-mousewheel font-sizing… AND canvas resizes… then you have a super-gui… where the gui is sometimes called “bulletproof”. (bulletproof generally means… you know… difficult to mess-up). 
Not very exciting reading… but… now we can see some issues with canvas resizing and GUI controls (buttons, labels, containers, etc).
Canvas resizing is a troublesome situation for GUI and sometimes for “click zones”. I once had a BIG canvas resize challenge that superhero @sebavan helped me with… somewhat. It was painful but full of learning. I was trying to use BJS Gui 2d as a diagram-making tool. Limited success.
PG #12 - My diagram - not surviving vert or horz canvas resize well at all.
PG #14 - Sebavan does MUCH MUCH work on it, using engine/canvas resize observers (thx Sebavan!). Not bad. The controls and connecting lines survive vert/horz canvas-resize… fairly well.
PG #16 - Here, Wingnut tries to “slew” the entire diagram across the screen as if it were a simple PICTURE/IMAGE diagram. The gui controls operate fine, but the connecting lines did not survive well. Maybe someday, I will try to advance “the GUI2d diagram” to be more-functional. But I must say… I was really torturing the diagram… and hoping it would be perfect.
Sorry for the long post. Canvas resizing is a big subject - possibly apropos to this thread, possibly not. Admin… delete/clean this post, as wanted. In many ways, it’s “too much”.