There really aren't any scenarios I can think of that an element would need to have `grid-column` set without being wrapped in another grid, so for that reason it is generally safer to set `grid-column` on all children than it is to set `max-width`. I would be surprised if I added an element only to discover that its width was being modified by a wildcard rule, less so with `grid-column` because grid placement is arguably the concern of the grid.
As a side note, I like this technique and have already had a good opportunity to apply it instead of the old padding & negative margins method or even flexbox + stretch (and I like flexbox), neither of which actually worked for this very specific case.
I fall into category 3 which is why I list it. It's not a technical reason so much as a code style reason so it is definitely subject to the opinions of each developer.
1. You can implicitly return things so it provides nice syntactic sugar
2. Using an arrow function results in `this` being bound in the way you'd expect (coming from something like C++) in all cases without having to call .bind(this) anywhere. I'll never forget seeing promise chains starting with `const that = this;` in order to keep the right reference throughout the promises.
3. You use it for the previous 2 reasons and use it everywhere in order to be consistent
The company isn't paying for your time in the car but it is paying for the space your desk in the office occupies. Would you argue that someone who drives 30 minutes more to the office than an otherwise equivalent coworker should be paid more?
On one hand, if you are worth $N to the company sitting in an office and produce the same output working from home, that output is still worth >$N to the company.
On the other hand, if the company isn't limited by geographic restrictions, it can find people who may produce an equivalent output and are willing to work for less.
So it is a balance between how in demand your skills are and how competitive the market is for those skills. In my opinion, if a company is in need of an employee and is willing to pay $N for the employee, simply being remote should not reduce that amount. It has advantages for all parties involved (improved employee satisfaction, lower office overhead, etc).
Ultimately it is a negotiation, the the company can try to justify paying you less because of cost of living adjustments unless you can negotiate otherwise. It's in their interest to get your labor for the best price possible.
I do agree that debugging async JS code is tricky depending on how your calls are structured. However, JavaScript is definitely debuggable. Stepping through minified code is a solved problem thanks to sourcemaps.
As a side note, I like this technique and have already had a good opportunity to apply it instead of the old padding & negative margins method or even flexbox + stretch (and I like flexbox), neither of which actually worked for this very specific case.