Tell us what’s happening:
I have no issues with the challenge, but I am wondering why bother with variables at this time when fallbacks are essentially duplicates to be hard-coded and updated manually.
It seems like doing the same thing twice, with more code to write the variables and instances. I mean, coding, --red-color: red; and background: var(--red-color); is much more code than background: red;
Using newer code doesn’t seem very DRY when fallbacks are needed to be coded alongside.
The fallback is there for compatibility. It is usually used to give a color in case the browser is really old - not necessary to use everywhere. And there is already a mess to do to have some things work in all browsers…
But imagine you color all your website in three shades. And you suddenly decide that the darkest one is too dark, and you want to change it (for example from #223377 to #345588)
You could go through your css and change one by one the values… or you could go to the root declarations and just change the value of variable --darkest-color
I understand the concept of how the variables work and how they would save time, such as in the case you presented. However, a coder would still need to initially hard-code and then change all of the fallback declarations one-by-one, right? If that is so, I don’t see the advantage in coding the web together with lengths of string (visualise that - the modern internet with string hanging down (fallbacks) to connect the old internet (old browsers)) Wouldn’t it be simpler to use 100% compatible code in the first place, or just ignore the 1.x% of old browser users and code for the contemporary world?
Of course it would, but if someone wants you to build an app that works in browsers that don’t support newer features but at the same time you want people who are using browsers that do support newer features to take advantage of them, this is the situation you find yourself in.
Generally, once you work for a company that makes money, ignoring sections of your customer base without extremely careful research to see if it impacts bottom line is not a good option.
There are multiple automated ways to deal with this, this part of the curriculum is explaining how fallbacks are done, in practise you would use a tool that added them automatically.
Of course, I would do what I was asked to when working for an employer / client.
Coding something once that works with all browsers ignores no users at all, which could save time and money by not creating more code that duplicates exactly what the 100% compatible code does, especially when the 100% compatible code is mandatory. That would reduce costs and maintenance. But as you have mentioned tools that do all of that, it’s perhaps a non-issue.
How about having a css file for old browsers and one for new browsers, and then have some kind of script to read the what is it, the agent or something, and load the css file for that browser type? That would keep old and new separate rather than the old bulking out a modern css file.
That used to be standard practise about 10 years ago when there were different Internet Explorer versions and they all allowed you to specify things in specific ways to only target specific versions. So you might have an IE6.css IE7.css IE8.css that all added rules that targeted those browsers. You can do it right now with things like Modernizr, which used to be heavily used and is now gradually becoming completely obsolete (it could add classes to body for features that were supported). Separating into different files is a bad solution: as much as possible, things that belong together should be co-located
Wouldn’t it be simpler to use 100% compatible code in the first place, or just ignore the 1.x% of old browser users and code for the contemporary world?