GusGF

Okay I missed that condition i.e. that a parent (as there can be many) must not have position static if it is to contain the absolute child element otherwise it uses the HTML element. An omission (W3Schools left this little caveat out too) to catch out the unsuspecting and throw them into absolute confusion.
I also made the error of not setting/uncommenting the absolute element position helper properties i.e. top, bottom, right, left, in my example. After reading your reply and using the helper properties it's now making sense.  
 

When you do the console.log you're adding the JSON object to the string of Axios Response, so the JSON object is being converted to a string, hence the object Object.
If you do it as two seperate lines, like
console.log('Axios Response'); console.log(response.data); Then it will be outputted as the actual object.
With it being an HTTP Request though, rather than outputting it into the console, what I'd do is open the Network tab of the browser development tools, and select the XHR tab, and then the request will appear in there and you can inspect the full response body there without having to log it.

Thank you for a great answer that's exactly what I was trying to understand ☺️

You have a syntax error in the first one.
You wrote
margin; 0px 10px; Instead of 
margin: 0px 10px;  
Notice the : just after margin.

There's nothing wrong with using something like Gulp to compile frontend assets, in fact plenty of themes have this built in. The company I worked at use Webpack with Wordpress because it's basically impossible to use ES6 modules and modern JavaScript without a compiler.
As for that development process, if you're dealing with a site that's getting traffic, you don't want to be playing around with code that's touching production until it's ready to be shipped. Not only should you always be working locally, your local environment should mimic your production setup so that you can use Git to deploy your changes and not edit using FTP. It's also slow to work like that and error prone, it might be your way of working but you wouldn't be able to do this at any professional company. Even though it's more complex initially, we have processes like this in place to make it easier for us to develop and safer to get code out the door, the complexity is often worth it, especially if you can't guarantee what you're pushing to production won't break.

I'm sorry but this  is a really outdated approach.

You want to develop and run locally even with a WordPress website.  Tools like Gulp, Webpack and so on will bundle up and transform all the frontend code (might be transforming Sass into CSS, ES6 into ES5 Javascript — You can do much, much more) to make sure it works before deploying (Obviously adding automated tests, linting etc on top of this is definitely worthwhile)

Ideally it should be a very rare event that something you deploy live is broken, you DEFINITELY don't want to use the live environment as a testing ground.  Rollbacks through Git are ok, but a bit slow if you have a high traffic website, if you have a proper deployment pipeline setup then you can just re-deploy an old (working) instance which should take just a few moments.

Also suggest use Git over SVN, In fact I've never worked anywhere that doesn't use Git, however any version control is better than none.  With Git and Github you can auto deploy when branches get merged into master (known as continuous deployment, this is typically proceeded by continuous integration whereby various automated tests and checks must pass before a branch can be merged).

Back in my WordPress days we'd also have way more than just the theme in code, the functions file for instance would be heavily modified, we'd remove much of the dashboard from the consumer so they can't mess things up e.g. only allowing them to update existing pages, or possibly adding new ones based on pre-defined templates.
In fact those using WordPress now I'd strongly advise them to use it only as an API https://developer.wordpress.org/rest-api/ then you're fully in control of the client side code.  You can even have a backend that for instance could take this JSON data from WordPress and transform that into GraphQL which you expose to your frontend, basically you have far more options this way and aren't tied into the WordPress way of doing things, your clients are none the wiser as they still make changes in the WordPress dashboard.