No offense, but this strikes me as another example of someone diving for fancy CSS layouts before they understand enough about HTML to be telling others how to use it. Though that’s to be expected when you list the outright scam based in lies and disinformation that is W3fools as a ‘favorite’. Only thing you can learn from them is how NOT to build websites — much like other lies and outright bad practices in this industry like all the hot and trendy “Framework” rubbish.
The LABEL tag exists to tell users what a INPUT, SELECT, or TEXTAREA is, and is not someplace you would/should be plugging the results of a calculation. Just what is that LABEL for? What is it describing? Just like the “PLACEHOLDER is not a LABEL” mistake people piss on forms with all the blasted time, the use of a label tag there seems not just inappropriate, but likely confusing for non-visual UA’s. Makes even less sense now that we have HTML 5’s OUTPUT tag.
HTML tags have meanings, and if you aren’t choosing the tags for those meanings or just making up your own meanings, you’re doing it all wrong.
This is also an example of diving for grid over something simple, creating a slew of excess style for no good reason.
Now, don’t get me wrong, it’s a great example of how to use grid, it’s just a bad example of WHERE to use grids… from the use of pixel metrics on text content (a possible WCAG violation), to LABEL on things that aren’t form labels, to a lack of type=”button” resulting in it likely attempting a form submit (if there’s no form that’s semi-acceptable), to the simple fact thanks to template-area you’re making it many times larger in terms of the requires CSS than it needs to be. Just set box-sizing on them, float them, organize them by code order, and be done with it.
Seriously, move button#equal before button#dot, swap the LABEL for OUTPUT, then use this:
border:1px solid #FFF;
Boom, done. 464 bytes of CSS where you were using 1.72k. Just hit all the buttons for uniform style at the start, adjust the two or three that need adjusting after, and it goes way faster than having to declare values on each and every blasted one.
Of course, since such elements would be scripting only functionality, in production code they would have zero business in the HTML in the first place… but for testing the layout concept we can let that slide.
Grids are great for complex columnar layouts where you require equal heights or min-heights when the content is dynamic and/or different unpredictable sizes. It is a poor choice for predictably sized elements where you have proper control, as it can make you write far, far, FAR more code than you need to do the job.
It’s just another tool in the bag, and shouldn’t be treated as a catch-all.