Last modified: 2006-10-29 12:06:33 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 7731 - CSS misunderstood in skins/monobook/main.css
CSS misunderstood in skins/monobook/main.css
Status: CLOSED INVALID
Product: MediaWiki
Classification: Unclassified
General/Unknown (Other open bugs)
unspecified
All All
: Normal normal (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-10-28 04:30 UTC by Schnargel
Modified: 2006-10-29 12:06 UTC (History)
0 users

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Schnargel 2006-10-28 04:30:51 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.
Comment 1 Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-10-28 22:51:42 UTC
"On the fly" presumably means "without modifying the file itself, via some kind
of hook mechanism" rather than "different for each user".
Comment 2 Schnargel 2006-10-28 23:43:52 UTC
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.
Comment 3 Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-10-28 23:45:08 UTC
Which it should be able to add to the stylesheet.  On the fly.  In case it needs
one not already provided.
Comment 4 Schnargel 2006-10-29 00:01:37 UTC
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?

Comment 5 Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-10-29 00:11:23 UTC
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?
Comment 6 Schnargel 2006-10-29 00:43:40 UTC
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.
Comment 7 Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-10-29 00:59:16 UTC
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.
Comment 8 Schnargel 2006-10-29 01:28:35 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links