Help:Page styles

A CSS "stylesheet" can be applied to a Index page, which will allow every Page: namespace page within it to share the same styling. This CSS is automatically included when pages are transcluded using the  tag.

You do not need to use CSS for a work if you don't want to. It is provided to make life easier, not harder.

How to apply CSS
The CSS is read from the  subpage of the Index page. If this page does not exist, no styles will be applied by default by the ProofreadPage extension.

Note: this is different to the CSS field in the Index page, which only applies to the Page namespace and does not transclude.

You can redirect a  to another CSS page (for example if a set of volumes share the same styles) but the redirect page may need to have the "content model" changed to "wikitext" (from "sanitized-css"), which currently requires an admin.

Where the CSS is applied
Index-specific CSS is currently applied automatically in the following places:


 * In the Page namespace of that index
 * On the Index page itself
 * On the transcluding page when pages are transcluded using the  tag.
 * Note: is is not applied if you directly transclude with  syntax, or with page. Either avoid these constructions and use the   tag (recommended) or you must manually invoke with.

How to write CSS
The CSS is a subset of full CSS called "sanitized CSS" provided by the TemplateStyles extension. It is the same as normal CSS, but it has restrictions on certain properties:
 * Some "rarer" CSS properties are not supported yet
 * Data URLs are not allowed
 * Image URLs not from Commons (or Wikisource) are not allowed

The CSS will only apply to the page content (it will not affect the rest of the Wikisource UI).

Classes and IDs
You can target CSS with "classes" and "IDs". Classes can apply to any number of elements (and any element can have any number of classes, separated by spaces). Any element can have an ID, but it can have only one, and it should be the only element on the page with that ID.

Classes are targeted by CSS rules with a dot prefix, and IDs with a hash

The following spans have classes and IDs:

Paired with this CSS:

The result is something like this:

 

Inheritance
You can target elements that are children of other elements with the "child" and "descendant" selectors:
 * Target direct children with
 * Target all descendants (any number of intervening "generations") with

For example, if you have Wikicode that produces the following HTML:

Then you can have CSS like this:

Cascading
The "C" in "CSS" means cascading. This means that the rules can override each other in a well-defined order. For each property, which rule is applied is worked out like this:
 * Styles set directly on an element have priority, otherwise,
 * More "specific" styles have priority
 * If two rule have the same "specificity", the one that occurs last has priority

"Specificity" has a certain defined meaning, but generally speaking it is a measure of how "precise" the selector is. For example in the following HTML and CSS:

In this case, for the  element inside the   element, the more specific selector   "wins" over the less specific   and the element gets the style.

What to use CSS for
CSS is ideal for applying things that would otherwise require very tedious, repetitive or verbose inline styles:


 * Sizes and spacings of chapter headings
 * Sizes of block-quotes and surrounding spacings
 * Formatting of lists (for example adjusting bullet points)

Due to the ability to use selectors like, they are also excellent for reducing bloated inline styles in tables.

Be semantically useful
CSS is one half of the structure-style separation-of-concerns provided by HTML (structure) and CSS (style). To use it to its maximum effect, it should be used "semantically". That is to say, provide meaning to content and then use that meaning to apply styling.

For example, this is semantically empty:

whereas this gives meaning to the first words:

And can be targeted, along with all other characters' names, with this CSS:

You should also not abuse Wikicode syntax just because it gives you a shorthand for a different HTML tag which you want to use to target with CSS. and  provide   and   elements, representing "description list" terms and descriptions, respectively. Only use them where this makes semantic sense (for example, a glossary or dictionary).

If you have a list,  (unordered) or   (ordered) are usually the correct choices.

What not to use CSS for
You should not use Index-based CSS to provide:


 * Indentation of paragraphs, even if the original work had them (see Style guide). Indentation of list items is usually acceptable, within reason.
 * Removal of spaces between normal paragraphs, even if the original work did not have them (see Style guide)
 * Global changing of fonts (e.g. serif), justification, font size or line heights (even if the original work had small or dense print)

All these should be provided through Dynamic Layouts or user CSS.

Remember that not all users have full-capable CSS devices. For example, many e-readers can handle only a very tiny subset of CSS. You should not use CSS for any content that must be shown even if the reader doesn't support any CSS. For example, using CSS counters to number lists or  selectors to add dots after list numbers will result in the wrong thing being shown to users without CSS. As a rough guide, if it can't be copy-and-pasted, users will not see it when CSS is not available.

Avoid bare classes
You should also avoid using bare CSS classes in Wikicode when a template would do. For example, say you have a work that has character names typeset in a certain way, say . If you don't want to repeat the formatting for each occurrence, you should define a template MyWork character to apply this (perhaps using its own TemplateStyles):  

And then use it as follows:

Avast, ye, !

The following bare CSS in the work's page content is bad form: Avast, ye, Long John Silver !

This is to say: the classes defined in CSS (including work-specific CSS) should nearly always be invoked via a template, not directly. It is much easier to reason about and maintain templates than HTML/CSS, even if the template itself constructs HTML/CSS.

CSS vs templates
Some things are suitable to be handled by work-specific CSS, and other things are more suitable for a template. Consider using a template if:
 * The desired output requires "structural" elements like HTML tags.
 * The desired output is useful in other works (i.e. it is not work-specific). You can redirect the CSS subpage, but this means you forfeit any dedicated styles for this work.
 * As above, the styling is work specific, but so is the application. In that case, a work-specific template is more appropriate. Per-work CSS is more suitable for applying work-specific styling to generic classes.

You can still target the output of templates with work-specific CSS (the template in question should set a class to allow this).

The following are some templates set classes that can be usefully targeted with CSS (others can be found in Category:Templates applying classes for page styles):


 * pseudoheading:
 * The overall heading element has.
 * Derived templates apply other classes.
 * rule
 * The  element has class.
 * section end rule
 * Use this specifically for rules at the end of sections/chapters.
 * The  element has class   and classes starting.
 * signed
 * The element has class.
 * running header
 * The outer element has class.
 * quote
 * The  element has class.
 * block center
 * The main container has class.
 * If used, the title element has class.
 * index list
 * The main container has class.

What if I want CSS for a single page
If you have CSS that applies only to a single page (for example, a table), you can still use TemplateStyles as normal:



This must be applied in the body of the Page page for it to transclude. Remember that the CSS will apply to the whole context where this one Page is transcluded—it will not be limited to this page only. So, use an ID or class or limit the effects of your page rule. For example:

will affect all tables on the final destination page, but

applies only to the element with the ID.

Class naming conventions
Since styles from multiple sources can be present on a single page, it is important to avoid name clashes between these style rules. For example, MediaWiki itself as well as the skin (Vector, etc.) will add some classes, the Extension:Wikisource and Extension:Proofread Page extensions may add others, and there are classes used by templates. To reduce the likelihood of collisions we have developed some conventions for how to name classes from different sources, based on giving the name a prefix indicating its origin.

There are historical exceptions, both here on English Wikisource and in MediaWiki, but diverging from these conventions in new content is strongly discouraged (and if you update old content please consider modernizing it to these standards).

For Page styles you'll mostly want to use the  prefix. This prefix is reserved for use within each individual work, and so templates and site-wide styles will never interfere with it. You may sometimes also need to override the styling for some templates (some newer templates are explicitly designed to be styled from Page styles), in which case you'll find the right classes with a  prefix on that template's documentation page.

'''NB! If a template does not document overridable classes then it is not safe to style it, even if you notice a class it uses. Internal classes in templates can change at any time and it is in general not possible to detect and update any outside uses of that class.'''

You may also sometimes need to use the  prefix. This prefix is reserved for use not only within a single text, but for some exceptional use within that text. Maybe for a single page that has different formatting than the rest of the text, or maybe it's temporary while you test something out. You can achieve the same with more unique class names, but the double underscore prefix also signals to other contributors that this class is special in some way.

Some specific class names are conventional (but not mandatory) to use for certain elements of books that are common.

Example page styles
Below are some example Page styles style sheets you can cut and paste into your own projects. If you're lucky you can use them directly for simple cases, but most likely you'll have to tweak them at least a little bit. The texts we cover are not all that uniformly laid out so some adaptation for each text is to be expected.

Tables of contents


A lot of tables of contents boil down to a two or three column table. The structure isn't that complicated, but coding it up in MediaWiki's table wikitext and templates is often very complex due to being row-oriented where the styling in the original is really column-oriented. Page styles using the CSS  selector (and the   and   shortcuts) can really help with this.

Simple two-column table of contents
One real life example is this table from The Works of Xenophon vol. 3 pt. 2.



Ignoring the pseudo-chapter heading ("Contents"), this table consists of two columns: one for the chapter titles and one for the page number on which it starts. The chapter titles column is left-align, uses small-caps, and has a hanging indent. The page numbers column is right aligned and has a little bit of space separating it from the chapter titles. In the row for the long chapter title that actually wraps we can also see that the chapter titles are vertically aligned to the top of their cell, and the page numbers are vertically aligned to the bottom of their cell. In other words, the page number is vertically aligned with the bottom of the last line of the chapter title.

This could be represented in wikitext with this structure (links omitted for simplicity):

Without Page styles this would render as:

Somewhat functional, but not a very good representation. We can do a lot better with some simple and fairly reusable style rules.

First we need to make the table centered in the page.

Then we make chapter titles small-caps, apply a hanging indent, left align (rather than justify) the text, and set the vertical align to the top.

Next we need to align the page numbers to the right and vertically to the bottom. We also want a little space between the page numbers and the chapter title, even for long titles, and this is a convenient place to add it.

Putting it all together we end up with this:

That's much better, but there are still some glaring problems. The heading for the page number column is a bit off, and the chapter title "Annotated Analysis" is way off. The reason is that these two cells deviate from the others in the table: we've coded both of them to span both columns so they are getting styled as both the ":first-child" and the ":last-child". So because these two cells are different we need to add separate style rules for them.

With these extra styles in place the end result is:

It's still not a pixel-perfect replica of the original page layout, but that should never be the goal. This version preserves enough of the original layout to be recognizable and preserve the feel of the original, without wasting inordinate amounts of time and volunteer effort.

Simple three-column table of contents
Another very common structure is the three-column table of contents. Here from Heart of the West:



That is a fairly simple three-column table. The first column is the chapter number, here as a roman numeral. The second is the chapter title. And the third is the page number. The chapter numbers are right-aligned, the chapter titles small-caps, and the page numbers right aligned. There's some spacing between the chapter title column and the two columns beside it. Long chapter titles also wrap with a hanging indent, so we need to vertically align the contents of each cell to make them match: the chapter number and chapter title to the top, the page number to the bottom.

This boils down to a wikitext structure like this (wikilinks and heading omitted for simplicity):

With no styling this renders as:

First we need to make the table centered in the page.

Then we need to style the chapter number column. It is the first column of the table so we could have used, but since we have more than two columns in this table it is better to use   so the selectors are consistent for all three columns.

Then we need to make the chapter title left- and top-aligned, small caps, and turn on hanging indent.

And the page number column right- and bottom aligned, with a little space between it and the chapter title.

With these styles in place our table will render like this:

Much better. Now all we need are to style the column headings for the chapter number and page number columns:

Because the heading for the chapter number spans two columns it will be affected by styles applied to both columns, and the heading for the chapter numbers will be affected by that column's styles. Therefore the selector used has to be more specific in order to override the general styles, in this case by specifying the element type in addition to the class name.

With that in place the final rendering will be:

Other tables


No left or right outer border
A common style for tables is with thin borders around all cells, including the outer edges of the whole table, except for the left and right outer edges. This can be achieved by the following custom styles in the work's Index CSS:

You can then add the class  to your table's wikimarkup:

Which will then render as:

Adding some cell padding and aligning the cell contents is left as an exercise for the reader. 😎