|
Re: your comment and the others below The variables argument is the only one I can truly get on board with. I really wanted variables. Find + replace in your editor for something like #fafaf0 isn't exactly error-prone or hard to do, so it wasn't ever a huge problem, but variables would have been very nice. Pertaining namespaces, that's what the cascading part was made for. I had 4000+ line CSS files for large ecommerce websites where I had 5 different declarations of some classes (e.g., .item), but using proper selectors and understanding specificity meant never having a problem. Pertaining large files, @import(...) always worked for me. For the most part, I'd use one large file (hence 4000+ line files mentioned above) because it helped with load speed, which did suggest that there was value in a build tool that would read @import(...) statements and pull those files into one large file after the fact. But this didn't mean we needed a framework with its own syntax, etc.... even today, tools like django-pipeline will pull in and combine CSS files for you, in the order given, so that you can write your files separately and have them combined after. Pertaining z-index, I never had an issue with this, except with drop-down menus, but even then it was intuitive and consistent that the next element down will be 1 layer above the one directly above it, and it was also intuitive that nested elements' implicit z-indexes would be relative to their parents, etc. |