Comrade:CriticalResist/sandbox/Library documentation

The library relies on these templates:

• Template:Library homepage
• Template:Library card
• Template:Library card mini

There is also a Module:Number of works to display the (X works) mention in the cards.

Library_homepage contains the overarching CSS for the div containers that will contain the cards on the library homepage in /style.css. It also sets up the library_card and library_card_mini css. It used to be that each template contained its own style, but I moved everything to Library_homepage.

There is also some CSS in MediaWiki:Citizen.css specifically for the built-in dark mode. It could probably be brought to the Library_homepage css.

It's otherwise pretty self-explanatory, especially when one looks at the user guide for the new library. Everything works with simple HTML and CSS.

The grayscale and scaling effect is realized in CSS in the library_homepage stylesheet, so you need to upload colorized pictures (we just did it with free AI tools online for older pictures). If you don't specify a picture for the big cards a placeholder image will be used instead, but it won't be centred properly. To fix this we should just upload a placeholder picture in the correct aspect ratio. Mini cards don't have a default placeholder image.

---

In the library page, we have div containers for every heading and subheading. .library-container is used for the big cards and .library-container-mini is used for the mini cards. You just open this div tag and put the appropriate templates inside it, one after the other. Each container can only be used for its appropriate card type. The CSS of these containers is controlled from the library_homepage template.

The big cards are simply flexboxes displays, but the mini cards had to be CSS grids to display properly.

Library homepage template

This template styles the library-container and library-container-mini to be a flexbox and a grid respectively. It also does some mobile styling for the mini-card container since we stack them in a single column on mobile (vs 4 for desktop).

It also handles the more "frequently applied" stylings, such as the grayscale filters and zoom in effects. These used to be in every template but I feel it makes load times worse because you need to call the Library_card css file for every single card that appears on the page, right? I can't confirm it but I feel that's how mediawiki would work. So with this "parent" template, the entire CSS gets called only once.

This solution means that you need to call the Library homepage template on any page which is going to contain library cards (realistically we could use them for tons of stuff other than library). If you forget to call this template, you'll know right away because it will look atrocious on the page.

It used to be that each card template had its own entire CSS but I moved everything to the library homepage and the two templates don't call any CSS anymore. This should reduce load times which were sometimes a bit long (relatively speaking) on the library page due to how many cards there are.

This also means the grayscale effect gets repeated for both the library card and the mini card in the CSS, but it's the same filter for both cards (it goes from 100% grayscale to 3% on hover). This is because I organized the common CSS file with library card styling, mini styling, mobile styling in this order.

If you want to change the filters, you need to do it for both cards (look for img:hover clauses preceded by a class).

Mini cards don't have the scale-in effect applied because they're so small it would barely change anything.

Big cards

The images in the big cards have position:relative. This allows us to specify a top and left position in pixels in the template directly (it's a parameter).

It's pretty clever how it works. The card has a fixed size whether on mobile or desktop which makes things easier. There is first .library-card-TOC (table of contents), which is an <h6> tag, the lowliest of all headings. The only thing this does (it's set to a height and width of 0px so that it doesn't actually appear on the page but the HTML still gets parsed, whereas with display:none, the HTML would not get parsed) is make the card {{{name}}} parameter appear in the table of contents that MediaWiki creates, which makes the library browsable.

However, MediaWiki reorders HTML headings itself to create its table of content. That means it doesn't matter that it's an h6, it will still appear as the proper heading or subheading natively.

Next we specify an image file which will link to a category. The library card can only link to a category because in the template, the link looks like [[:Category:{{{link}}}. Note the colon before Category, which specifies in wikicode that it is meant to be treated like a hyperlink and not applying the category to the page!

Then we have another container for the content, which creates the white box with the card name and number of works displayed. The reason we have that is because this blank box needs to be filled in with a color, otherwise the picture (which has a z-index of -1 and is scaled at 1.1 so that it properly covers the entire area it was given) will overlap on the box a little bit. The image is in its own container for proper sizing.

Since we scale in at 1.1 by default we only scale to 1.2 on a hover which is a net 0.1 increase.

This is also where the night mode CSS comes in. You just specify your background-color as var(--color-surface-0) in the Citizen.css page and Citizen will automatically parse it. For other skins which have only a light mode, this bug doesn't happen and the box is plain white but I don't remember setting a color for it other than the Citizen variable. Weird!

The only parameters for the end user are the image path, card name, category name, and finally top and left offsets (hard-coded in pixel, you can change the unit in the Library_card template but there's no need because pixels are the most precise unit).

Mini cards

The mini card images repeat the same CSS, namely the grayscale filter (but no scale-in effect or box-shadow). They also use many more parameters in their template because you can type in any kind of text you want and add the links yourself. That is to say, the mini card doesn't need to link to a category.

They also use the same <h6> trick as the big cards.

They are in a grid display, but the grid changes depending on if you're on mobile or desktop to allow either 1 column or 4 respectively.

Regarding the grid, something weird happens (probably conflicting with another piece of code): it skips one column out of two. Using some math, I simply made every other column in the grid the size of the margin I wanted, which makes it look like there's the right amount of columns and margin.

This means there's actually 8 columns on desktop and 2 on mobile, but we only use half.

Their parameters are also image path, text that appears next to the image (can contain links), name in the table of contents, and link for when one clicks on the image. There's the same amount of parameters as the bigger cards but it's a bit more complex to use with lots of overlap. However, this was the only solution I found to make mini cards be able to link to any other page we want, category or not.