TQ
dev.com
Blog about software development
25 May 2016 - by 'Maurits van der Schee'
There are some self-proclaimed "expert" front-end developers on the Internet talking about "guidelines" for large scale CSS projects that are absolutely absurd. I like absurd jokes and I am pretty amused by these "guidelines". But a lot of people seem to be taken these "technologies" seriously. To protect the industry and make it a less toxic environment for beginners I will debunk these "CSS naming conventions" in this post.
The following acronyms promote absurd use of CSS and beginners should be aware that these are jokes:
They all promote redefining CSS elements in class names and/or class names that represent elements in the HTML. They claim to do this to "avoid redundancy", "prevent clutter" and "improve scalability", yeah right!
I can agree on one point: writing all your CSS inline (in the "style" property of your HTML5 elements) is probably not such a good idea if you ever want to change the layout/theme of your application.
Nevertheless the above "inventions" are pretty stupid. By moving the styles from the "style" to the "class" property you are only making matters worse.
The following ideas are much better, but should probably still be avoided for efficient and scalable front-end development:
They are trying to structure the CSS, working around some problems, but by not prescribing the HTML structure they are missing an essential factor and your large scale project will still be a big mess.
I hear you asking: "If you know so well that all this is wrong, then what is the right way?" Fortunately the answer is simple: A style-guide using semantic class names in combination with prescribed HTML for UI elements! Where the class names describe what the HTML represents and the styles are applied accordingly. These class names should be as abstract as possible, representing the intention of the HTML element(s) in the style-guide and not the detailed representation.
I feel that Bootstrap was the first to try to do this and developers loved it. Other great examples of this philosophy are Semantic UI and Zurb Foundation. Now go check all of these out and don't get back here before you gave one a serious try! Oh, and if you think these are missing some important UI elements I can tell you: they aren't. You don't need those fancy custom UI components to create a good intuitive UI, it only requires recognizable UI design patterns.
The surprising thing about these frameworks is that they do not only allow the front-end development to scale, they make the entire software development more efficient. By introducing a style-guide that prescribes CSS and HTML for a set of approved UI elements a very precise split of responsibilities is introduced. This means that direct dependencies in the software development process, between front-end and back-end developers are removed and the whole process becomes more efficient.
Some front-end developers resist using the above frameworks, afraid of the efficiency these style-guides bring, afraid that they are no longer relevant. Others embrace this innovation and excel, being more valuable and productive than ever. Lots of front-end developers are vain enough to redo this excellent work into their own, often mediocre, style-guide. Great for them, as it sounds like an awesome and important challenge. But I guess that only if you work at Yahoo, Google or Facebook this may (from a business perspective) be a good idea.
PS: Liked this article? Please share it on Facebook, Twitter or LinkedIn.
Subscribe