Matthias Grimm wrote:
Furthermore the definition of a color like this: __lightgray__="#f5f5f5"One of the problems with CSS is its not possible to define your own colour constants. So making a CSS results in using the same colour code in many places throughout the stylesheet. Simplifying that to a small number of constants makes that much easier to handle.
makes not much sense to me.
Easier for the theme editor to understand would be to name the patternsI don't agree with moving the individual style colours. All these elements are defined in the style sheet, generally in one place only. It doesn't make sense to redefine them again, at least not to the detail implied in your example. Something in between your example and the current number of colours may make sense
according there function. For instance __link_external__ for an external
link or __tab_border__ for the table border. This could look like this:
e.g.
__dark__ = #666 __border__ = __dark__
In general these all are single style rules. As mentioned above, I can't see the point in shifting their place of definition.---- style.ini example (partly) ---- __link_visited__ = "Purple" __link_extern__ = "#062efa __text_headline__= "#000000"
__button_light__ = "#bfc9fa"
__button_back__ = "#5d77fa"
__button_dark__ = "#0524c1"
__button_text__ = "#ffffff"
__input_text__ = "#000000"
__input_back__ = "#e8ebfa"
Maybe plugins should have ability to "add" to styles.ini. I thought about this briefly, but I reckon we have to watch the solutions becoming more complex than the problem. Especially as lots of people understand CSS but not so many understand dokuwiki style.ini files.
In this context I have another question: How are plugins themeable? In
case of the user manager I tried to change the CSS for the disabled
button, but the default css file seems to be priviledged.
Chris -- DokuWiki mailing list - more info at http://wiki.splitbrain.org/wiki:mailinglist