As you develop complex software you identify pieces of code that appear in lots of places, and you factor it. You create one piece of code that can be called from lots of places so you don't have to keep writing it over and over, and so you can maintain the code more easily. It's how you make progress in software.
An example. A bit of code that displays the contents of a log database. I have lots of software that throw messages onto a log so that someone wanting to see what the software is doing can do so quickly. There's a routine called log2.view that takes the address of a log and returns an HTML table that can be inserted into a web page. Screen shot.
So now the guy who's working on the log displayer code has a tough problem. He can no longer include the styles with the table he generates, because those would be the last ones the browser sees and any efforts the app developer took to override them would be ineffective.
1. While the core code is in development, include the styles with the code you generate. This makes it easy to tweak the defaults and get it so that it will work in most cases without any overriding at all.
2. Later, when the core code has been deployed and is being used in a few apps, the pattern of use should be established and the things that must be specified are known, and these cannot be overridden.
4. Find a way to publish sample styles that give developers who might use your toolkit an idea of some values that create an attractive interface. But they have to include those styles in the overall stylesheet for their work.
The second way of dealing with it is at the code level. Let the code that invokes the log viewer include parameters to the call that specify values for the crucial styles. And you can bake those into the HTML. So you're not using the cascading-ness of CSS, but you are still providing a way to override the defaults. Now the very highest level code is controlling the styles that are inserted along with the HTML code that's being generated. Of course the parameters will have defaults. But it isn't always practical because often there is no code that's calling a library routine, or it is fairly far away from the place where styles for the app are stored.
BTW, see section 2.3 of this critique of Pascal written by Brian Kernighan in 1981. Seems to be the same problem. "Related program components must be kept separate."