From: Bharat M. <bh...@me...> - 2006-08-22 08:24:47
|
Christian Mohn wrote: >> Goal 2. Their appearance should be controlled by the theme. Ie, the >> CSS should not be hardcoded into any module, or if it is hardcoded then >> you should be able to override the CSS in the theme. > > Why not provide a "standard" css file for the widget wherever the widget is defined, but it'll look for a theme specific css file first? eg, check if there is a css file matching the widget name in the theme dir, if not include the stock one. > > That way you get a css either way, and theme developers get an option to override by placing the css inside the theme dir? It's trickier than it seems. In order for us to determine which CSS file to load, we have to have some code that can check to see if the theme overrides it. And that code has to execute *before* we finish writing out the <head> element, which is problematic because we may not even know if we want to use this widget until halfway through rendering the page. So at that point, it's a little late to go figure out which CSS file we want and include it. So even if we solve the "let the theme override the default widget" CSS problem we're still stuck with the "we don't know what widgets we're going to need CSS for" problem. I can't think of any solution for that problem that doesn't involve just putting all the CSS that we *might* need into the theme and having it available. That's more or less what we do now for the rest of our "standard" themeable constructs... -Bharat |