Help:Skins

From GRWiktionaryHelp

Isn't this what a wiki is all about? MediaWiki allows the user to choose a skin for page display. The new default skins are mainly based on CSS, so you don't have to change the page source to get a very different look.

• User styles -- many tweaks you can try in MediaWiki:Monobook.css or in your user stylesheet
• Gallery of user styles -- different skins for your browsing and copy&paste pleasure

Contents 1 Generic css classes for content 2 Two generic xhtml skins 2.1 External links/ inspirations 2.2 Advantages 2.3 Disadvantages 3 ESI 4 PHPTal templating engine 4.1 Simple benchmark 4.1.1 Cologne Blue 4.1.2 DaVinci 4.1.3 Standard 4.1.4 Paddington 4.1.5 Montparnasse 5 Related topics

Generic css classes for content

To allow better and more uniform styling for content elements (tables for example) a global set of css classes should be defined that can be referenced from the content.

Examples:

• w:en:Wikipedia:Article_series
• w:en:Wikipedia:Infobox

#mediawiki 21.2.2004:
(13:09:29) gwicke: for columns we'd need to provide some syntax extension to render the same class attribute for each cell in a column
(13:09:35) Jamesday: And the excuse is likely "no way to define a css style, so ai had to do it that way"(groan)
(13:09:59) Jamesday: Well, step one is to recognise col and colspan
(13:10:07) Jamesday: so it can at least be done in one place per column
(13:10:29) Jamesday: That is, col and colspan in HTML, not wiki table markup

(13:17:05) lexor: I suspect that "seriesboxes" are the most widely deployed styles at the moment, and taxoboxes for organisms

We need this badly on Wikisource. See The Communist Manifesto and On Lucy, Countess of Bedford for an example. Basically, we need a CSS definition for poetry (behavior of break line) and another one for texts (where we could define a text-indent).

For Wikipedia you could define an id for #thumbnailed-image and another one for #infobox. The derive from each class characteristic for the different infoboxes (plants, bacteria, etc) like #infobox .plant blah blah blah.

In summary, we should provide a standard so that skin developers do not necessarily need to build a PHP skin in order to get the desired page style. I was writing a skin once that was going to use the same menus, etc. and I had to break my head writing a PHP file for it, when in reality I should only need to write a style sheet that could define my skin (if I wish to use the same buttons, etc).

By the way, we should separate a style sheet for the main pages. For example, headers (<h1>-<h9>) on the main page need a margin-top/padding-top attribute of 0, while on the rest of the pages the attribute remains the same one as the default.

--Maio 13:25, 21 Feb 2004 (UTC)

---

Two generic xhtml skins

proposal and now implemented by Gwicke 13:46, 10 Jan 2004 (UTC)

I'd like to be able to create a new design with a new stylesheet and some images, without ever touching the php templates. As a base for this, it would be nice to have two well-structured xhtml skins:

• clean & lean xhtml: probably based on Tarquin's li template with some mix-ins from my second one. No major elements twice, only 2-3 single links such as 'edit this page' like in the Giza skin above the page content. Plays nice with ancient UAs such as Netscape and search engines.
• rich xhtml: has rich functional elements before the text, provides multiple instances of the same ui element above/below the content. For graphics-rich interface and advanced users. Unstyled very similar to the stonehenge skin.

These two should be as stylable as possible, providing many ids and classes to play with- very similar to the cssgarden xhtml file.

I would like to find a consensus on a few common elements (how the language list should be done in xhtml for example), and then we can do a first generic xhtml file based on this. Tarquin's li-layout is a good starting point imo. I've done a mockup that is structurally practically the same but looks completely different. We could merge these two as a start. The more versatile the structure gets the better.

With these solid & clean xhtml skins as a base people can hack away on the stylesheets, we could even make up a competition (contact css newsgroups, csszengarden, alistapart,...). If designers can easily tweak the layout and some nice, working designs come out of this, then the better for wikipedia i'd say.

What about Netscape4?

I think the best for Netscape 4 is to provide them an unstyled document that makes sense structurally, with the links below the text. From what i've read NS 4.0 now has a market share of 0.4% or so- we shouldn't sacrifice standards and usefulness to 99.5% of the users in favor of those 0.4%. Using import for the stylesheet hides it from pre-css Browsers automatically.

External links/ inspirations

• Csszengarden- demonstrates the power of css- the same xhtml for completely different designs.
• /*positioniseverything*/- layout structure. ordered borders is a very good base
• Plone- completely tableless design, section 508 accessibility, xhtml, all the browser fixes in place
• Edge Side Includes- new way to do trivial skinning variations using slots on distributed cache servers (Squid3) close to the client, increases cacheability drastically. Could for example insert a link to the user's chosen stylesheet into the head of a cached page without contacting the main servers.
• wired.com- was one of the first major sites to move to tableless xhtml/css

Advantages

• simplifies maintenance, only one set of templates to update
• enables designers to make new skins without touching templates
• could allow a user-specified header section for inclusion of user-specified css and js that can use the hooks provided in the markup, or a standard header from a dropdown
• templates can be thoroughly optimised for accessibility (access keys, structure,...)
• increases cacheability (especially with ESI)
• will coexist with smarty and other (all current) html templates (just another option)
• has the future potential to avoid a templating engine which could be a performance advantage
• Netscape4 users will finally have some reason to upgrade after all these years

Disadvantages

• I see a problem with skins such as Cologne skin and Stonehenge skin -- I think users will still want to use these skins, and I'm not sure we can easily make them all out of the same XHTML. -- Tarquin 11:13, 16 Jan 2004 (UTC)

Replicating Cologne skin's layout isn't that hard, the unstyled xhtml could be made very similar to the stonehenge skin (not sure about the dropdown though). Both would be candidates for the second (langer) xhtml version because several link sets occur in multiple places.

There's no need to replace any existing skin- the xhtml should be just one option, all other skins remain available. If it works and we have good equivalents of the current skins based on the two xhtml skins we could decide to switch completely. I'd just like to have a well-thought out, accepted, solid base for css designs soon to avoid duplicated work. -- Gwicke 14:49, 16 Jan 2004 (UTC)

ESI

http://www.esi.org/overview.html -- Allows a page to be constructed from multiple, separately cacheable & purgeable elements on the Squid Cache Server. Squid 3 supports this, but wasn't stable enough yet in January '04. With ESI the need for just two xhtml structures isn't absolutely necessary anymore, although i find it still desirable.

PHPTal templating engine

See m:PHPTal. Initial integration additional to smarty just done.

Simple benchmark

Some simplistic speed measurements i've done on my server (ab -n 1000 -c10 http://wiki.aulinx.de:8000/Main_Page) with the different skins and $wgUseDatabaseMessages = false;. The speed seems to depend mainly on the number of calls to wfMsg() to get translated strings. DaVinci additionally calls this for access keys for the links and (soon) context help strings for the main actions. The cost per wfMsg() call seems to be roughly 0.01 req/second less.

Cologne Blue

Requests per second:    2.51 [#/sec] (mean)

Connnection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0     4   46.0      0   791
Processing:  3109  3968  307.7   3928  4995
Waiting:     2901  3967  307.6   3923  4995
Total:       3109  3972  310.7   3930  5034

DaVinci

Requests per second:    2.59 [#/sec] (mean)
Connnection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0     0    4.7      0    51
Processing:  3005  3847  262.6   3817  4903
Waiting:     3005  3847  262.6   3817  4903
Total:       3005  3847  263.1   3817  4903

Standard

Requests per second:    2.62 [#/sec] (mean)
Connnection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0     4   50.0      0   867
Processing:  2867  3797  311.4   3777  4955
Waiting:     2867  3796  311.7   3775  4954
Total:       2867  3802  311.7   3780  4955

Paddington

Requests per second:    2.87 [#/sec] (mean)
 
Connnection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0     4   44.8      0   579
Processing:  2661  3463  346.8   3424  5032
Waiting:     2661  3462  345.7   3424  5032
Total:       2661  3467  361.8   3424  5611

Montparnasse

Requests per second:    2.82 [#/sec] (mean)
 
Connnection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0     4   42.2      0   565
Processing:  2701  3523  342.6   3493  5334
Waiting:     2701  3523  341.4   3492  5333
Total:       2701  3527  358.2   3493  5899

Related topics

• m:Thumbnailed images