Style sheets are built for cascading (therefore
the name)
The question isn't whether or not I understand that stylesheets cascade. The question is how complex we want things to be. My preference for a simple solution isn't based on ignorance of what can be done with stylesheets. It's based on my belief as to what should be supported in the context of OpenACS.
Hmm, this rule would make it quite hard to refine packages
or to define skins, modifying some properties of the default
settings.
Typically a page consists of the output from a single package script, combined with master templates.
In this case, we don't need a topological sort. The solution discussed in the OCT would put out CSS links with those from the outer-most master occurring first, next-inner master next, etc down to the those linked by the package script itself. This solution is far simpler than implementing a generalized topological sort.
This solution, of course, allows the package to overwrite global CSS if it choses to do so, though I still claim that doing so shouldn't be encouraged. We seek page-to-page consistency, after all. We want to simplify the theming of sites, not to encourage people to write packages that break whatever theme's been implemented for a site.
But if you insist, all you need is a package master template that defines a stylesheet that overrides the global defaults if that's what you want to do.
In the case of multiple package INCLUDE lib scripts, or multiple portlets, appearing on the same page, a topological sort doesn't solve the problem. If two different packages override the global form CSS in incompatible ways, the fact that both specify a REQUIRE GLOBAL CSS leads to two possible orderings:
link global form.css
link package a form.css
link package b form.css
or
link global form.css
link package b form.css
link package a form.css
So it's unwise for the author of either package to assume that their package will "win" the topo sort fight.
If you RELIABLY want your INCLUDElet or portlet to put out forms in a different style when both package a and package b appear on the same page, you should probably write a separate form template for each using CSS classes defined local to each package.
