Inherently CSS, Cascading Style Sheets, do not have to be busy or complex. Classic CSS 1 & 2 commands like color, margin, text-size, and others are easy to understand. However, CSS commands have 3 inherent layers of potential complexity. The first is the fact that every HTML element can have many CSS commands styling the look of the element as seen in the screenshot below taken from a W3Schools Try-it yourself edit session:
Highlighted in yellow are all the CSS commands that are used to style the H1 html element to look like:
This is a Heading
– Also note that P – paragraph html element has no CSS styling. This is the first layer of CSS complexity- the fact that one html element can have multiple CSS commands attached to it.
The second layer of CSS complexity is that one html element can have many different CSS commands applied to it all at the same time. In the example, an inline CSS Style command was used. But there are two additional ways CSS can be applied – a style block embedded in a page’s head block or using a link to an external .css file. These two CSS sources could also be applied to the H1 html command – then the question is which CSS styling takes precedence.
But to further complicate the use of CSS there are selector rules which determine how CSS will be applied to html elements. These rules are at the heart of using CSS for design and styling. But the full set of selector rules with their sophisticated class and id filters are not easy to master. This is especially true when multiple CSS selectors point to the same html element – then Cascading Styles Specificity and Inheritance rules have to be invoked. The browser F12 Inspector command reveals the problem:
Literally there are dozens of incoming CSS styles. Trust me, this makes not just WordPress but general website building challenging. WordPress Software developers responded with early and popular PageBuilders like Divi, SiteOrigin, and Visual Composer which took care of CSS styling rules in easy-to-use, drag and drop, WYSIWYG post and page builders.
But this is the source of the third layer of CSS complexity – the process of managing and resolving HTML+CSS layout and styling with a pledge of “no coding required”. Also a problem is using computational CSS frameworks like LESS and SaaS both of which concede “some coding required”. But to maintain “no coding required” as seen in ever more demanding responsive designs with layouts subject to complex media queries, conditional logic, zoom appearance/disappearance and transparency demands [with stickiness, animations, motion effects waiting in the wings] – modern day ThemeBuilders are hard pressed. So users see from Gutenberg Builder through Elementor ThemeBuilder to the new crop of tools like Breakdance, BricksBuilder, and Oxygen – all are stretched to the limits. These tools are having to switch from “No Coding Required ” to “Some Coding Needed” ; to mostly WYSIWYG editing to multiple and torturously deep drag/drop/click steps so semblances of easy to use can be maintained.
In effect ThemeBuilders are on the front lines of CSS development where rival CSS Layouts compete for allegiance. Here are some of the state-of-the-art alternative CSS framworks.
Summary
CSS is busy if not downright complicated. But software developers have responded with two sets of tools – 1)website wide styling tools which make corrections to a site needing styling refinements [see Styliser or CSSHero]. The second set of tools are WebSite Builders or WordPress PageBuilders/ThemeBuilders which have simplified Layout and Design for websites in general but present a smorgasboard of differing costs, runtime performance, ability to deliver “no-coding-required” and simple/easy to use design interface. The bottom line – if you want Style on your site, you may have to pay with behind the scenes Busy Complexity.