An observation I haven't seen anywhere else. 

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. 

Of course the table has styles, and those styles must have default values, and this is where we run into trouble. 

If you include the default values with the table text they can't be overridden. That means these must be the styles for every log table. 

But what if you've included the log in an app that has a blue theme but the log is designed to display in a red theme. Of course the app developer should be able to do that.  

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.  

I don't think there's anything to be done about it. It's a fallout of the design of CSS.  

I've found two ways to work with this limit -- here's the first: 

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.  

3. The others are not specified, you accept the browser defaults, or the defaults of the toolkits the app is using (jQuery, Bootstrap, etc).  

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."