Last modified: 2006-10-29 12:06:33 UTC
skins/monobook/main.css contains a comment /* TODO: #t-iscite is only used by the Cite extension, come up with some * system which allows extensions to add to this file on the fly */ Please note that CSS philosophy is that program output is supposed to refer to existing styles by making use of a well defined set of style definitions in a style file, not to create own styles on the fly for each purpose and possible output, which would be the same (read "as bad") as putting the style directly into the code. For example: if permanent version links, citation links and maybe more are to have the same appearance, there should be a class definition for this kind of links, which a) makes it possible to add more links of that sort anytime without creating more id-based style definitions in that file and b) makes maintenance of other style/skin files easier. This bug is just about the comment. Please remove it, it hurts.
"On the fly" presumably means "without modifying the file itself, via some kind of hook mechanism" rather than "different for each user".
That would still be the same as hardcoding a style into the source code. The idea of CSS is to separate the definition of the contents of a webpage from the definition of it's appearance. If a new style is necessary it should be introduced in the stylesheet(s), not by the code of an extension. If an extension wants to use a style it should refer to a class definition.
Which it should be able to add to the stylesheet. On the fly. In case it needs one not already provided.
For CSS you have to think the other way round. If it needs a new style it should be provided to the program, not by it. The program code should not be concerned with the way it's output is presented, be it in one of the many skins, a special css file for monochrome output, a screen reader or a braille device. Or how would a program choose a text color for output without knowing the background color, and would it add it's definitions to more than one stylesheet?
Each skin has a default stylesheet. Any changes to that stylesheet, whether made by installing extensions or otherwise, are easily overrideable by any end-user, or by the wiki. That higher-precedence stylesheets can change the background-color and lower ones don't get access to that, well, that's a deliberate failing of CSS: you can't make references to other statements, so anyone whose customizations get mucked up will have to update them to reflect the changes to the main stylesheet. If an extension has some element that needs to be styled, and which can't sensibly inherit from the core code's classes for some reason, where *should* it get the style info from? It should just be left unstyled? Is that always acceptable?
The cascading of the style sheets is a one-way only, that's just the way it is. To make proper user customization possible you need a proper documentation of the styles, explaining the used IDs and classes (which doesn't exist for mw). If you enable extensions to add something on the fly you make the situation even worse, since users can't guess what they don't know or can't look up in the existing css files. I didn't say to leave something unstyled (though in this special case I have doubts if that extra style is necessary). If an extension really needs a new style, it just needs to be added (separately) to the existing styles, and then you use it, like you use library functions in a software project if one your source files needs to read some data or to display something on the screen. And like libraries, style sheets are supposed to make your software independent from the hardware.
So any style that an extension might need should be added to the core code? What about third-party extensions, what do they do if they don't want to hack the code (and thus make updating a pain)? Some kind of hook is needed. Currently no way for extensions to add custom style rules exists, so they either have to require user hacks or use inline style if the needed style isn't in the main stylesheets.
Extensions don't need that many special styles, they need to integrate into the skins. But any style they might need should be in the style sheets. The output should fit to the page layout and the page design that's defined in the skin files and good skin files should have enough definitions for different kinds of outputs (and thus restricting themselves to some real style and not to arbitraryness). If an extension needs to output an error message there should be a class to display error messages. Then if one skin likes to show error messages in red it will be red and if another shows error messages in orange it will be orange. If an extension needs to show a link it will be in the color that the skin file defines. It's font will be the skin's font and if there's a skin displaying white text on a black background the extension's output will appear that way too. If a skin file defines a standard look for tables, any tables of extensions are expected to look the same. Why would extensions need to define own styles and what possibly needed styles are missing? And how could an extension create them without knowing the definitions of existing and future skin files? Simple example: You have a software that outputs some text using stylesheets and has nothing fancy defined yet and now you want to display some warning message in your text. The correct way to have it displayed with some emphasis is that you create a class for such warnings in your stylesheets. Now you have a stylesheet for screen output and there you define that class to output red text on a yellow background. The other stylesheet is for printing and since there are b/w laserprinters you rather make that class output boldfaced text there. Then you take that class name and use it in the source code.
