News for May, 2021
/* source: */
#top-bar .open-menu a {
        position: fixed;
        top: 0.5em;
        left: 0.5em;
        z-index: 5;
        font-family: 'Nanum Gothic', san-serif;
        font-size: 30px;
        font-weight: 700;
        width: 30px;
        height: 30px;
        line-height: 0.9em;
        text-align: center;
        border: 0.2em solid #888;
        background-color: #fff;
        border-radius: 3em;
        color: #888;
@media (min-width: 768px) {
    #top-bar .mobile-top-bar {
        display: block;
    #top-bar .mobile-top-bar li {
        display: none;
    #main-content {
        max-width: 708px;
        margin: 0 auto;
        padding: 0;
        transition: max-width 0.2s ease-in-out;
    #side-bar {
        display: block;
        position: fixed;
        top: 0;
        left: -20em;
        width: 17.75em;
        height: 100%;
        margin: 0;
        overflow-y: auto;
        z-index: 10;
        padding: 1em 1em 0 1em;
        background-color: rgba(0,0,0,0.1);
        transition: left 0.4s ease-in-out;
        scrollbar-width: thin;
    #side-bar:target {
        left: 0;
    #side-bar:focus-within:not(:target) {
        left: 0;
    #side-bar:target .close-menu {
        display: block;
        position: fixed;
        width: 100%;
        height: 100%;
        top: 0;
        left: 0;
        margin-left: 19.75em;
        opacity: 0;
        z-index: -1;
        visibility: visible;
    #side-bar:not(:target) .close-menu { display: none; }
    #top-bar .open-menu a:hover {
        text-decoration: none;
    @supports (-moz-appearance:none) {
    #top-bar .open-menu a {
        pointer-events: none;
    #side-bar:not(:target) .close-menu {
        display: block;
        pointer-events: none;
        user-select: none;
    /* This pseudo-element is meant to overlay the regular sidebar button
    so the fixed positioning (top, left, right and/or bottom) has to match */
    #side-bar .close-menu::before {
        content: "";
        position: fixed;
        z-index: 5;
        display: block;
        top: 0.5em;
        left: 0.5em;
        border: 0.2em solid transparent;
        width: 30px;
        height: 30px;
        font-size: 30px;
        line-height: 0.9em;
        pointer-events: all;
        cursor: pointer;
    #side-bar:focus-within {
        left: 0;
    #side-bar:focus-within .close-menu::before {
        pointer-events: none;
rating: +6+x

What this is

A bunch of miscellaneous CSS 'improvements' that I, CroquemboucheCroquembouche, use on a bunch of pages because I think it makes them easier to deal with.

The changes this component makes are bunch of really trivial modifications to ease the writing experience and to make documenting components/themes a bit easier (which I do a lot). It doesn't change anything about the page visually for the reader — the changes are for the writer.

I wouldn't expect translations of articles that use this component to also use this component, unless the translator likes it and would want to use it anyway.

This component probably won't conflict with other components or themes, and even if it does, it probably won't matter too much.


On any wiki:

[[include :scp-wiki:component:croqstyle]]

This component is designed to be used on other components. When using on another component, be sure to add this inside the component's [[iftags]] block, so that users of your component are not forced into also using Croqstyle.

Related components

Other personal styling components (which change just a couple things):

Personal styling themes (which are visual overhauls):

CSS changes

Reasonably-sized footnotes

Stops footnotes from being a million miles wide, so that you can actually read them.

.hovertip { max-width: 400px; }

Monospace edit/code

Makes the edit textbox monospace, and also changes all monospace text to Fira Code, the obviously superior monospace font.

@import url(';700&display=swap');
:root { --mono-font: "Fira Code", Cousine, monospace; }
#edit-page-textarea, .code pre, .code p, .code, tt, .page-source { font-family: var(--mono-font); }
.code pre * { white-space: pre; }
.code *, .pre * { font-feature-settings: unset; }

Teletype backgrounds

Adds a light grey background to <tt> elements ({{text}}), so code snippets stand out more.

tt {
  background-color: var(--swatch-something-bhl-idk-will-fix-later, #f4f4f4);
  font-size: 85%;
  padding: 0.2em 0.4em;
  margin: 0;
  border-radius: 6px;

No more bigfaces

Stops big pictures from appearing when you hover over someone's avatar image, because they're stupid and really annoying and you can just click on them if you want to see the big version.

.avatar-hover { display: none !important; }

Breaky breaky

Any text inside a div with class nobreak has line-wrapping happen between every letter.

.nobreak { word-break: break-all; }

Code colours

Add my terminal's code colours as variables. Maybe I'll change this to a more common terminal theme like Monokai or something at some point, but for now it's just my personal theme, which is derived from Tomorrow Night Eighties.

Also, adding the .terminal class to a fake code block as [[div class="code terminal"]] gives it a sort of pseudo-terminal look with a dark background. Doesn't work with [[code]], because Wikidot inserts a bunch of syntax highlighting that you can't change yourself without a bunch of CSS. Use it for non-[[code]] code snippets only.

Quick tool to colourise a 'standard' Wikidot component usage example with the above vars: link

:root {
  --c-bg: #393939;
  --c-syntax: #e0e0e0;
  --c-comment: #999999;
  --c-error: #f2777a;
  --c-value: #f99157;
  --c-symbol: #ffcc66;
  --c-string: #99cc99;
  --c-operator: #66cccc;
  --c-builtin: #70a7df;
  --c-keyword: #cc99cc;
.terminal, .terminal > .code {
  color: var(--c-syntax);
  background: var(--c-bg);
  border: 0.4rem solid var(--c-comment);
  border-radius: 1rem;

Debug mode

Draw lines around anything inside .debug-mode. The colour of the lines is red but defers to CSS variable --debug-colour.

You can also add div.debug-info.over and div.debug-info.under inside an element to annotate the debug boxes — though you'll need to make sure to leave enough vertical space that the annotation doesn't overlap the thing above or below it.

…like this!

.debug-mode, .debug-mode *, .debug-mode *::before, .debug-mode *::after {
  outline: 1px solid var(--debug-colour, red);
  position: relative;
.debug-info {
  position: absolute;
  left: 50%;
  transform: translateX(-50%);
  font-family: 'Fira Code', monospace;
  font-size: 1rem;
  white-space: nowrap;
.debug-info.over { top: -2.5rem; }
.debug-info.under { bottom: -2.5rem; }
.debug-info p { margin: 0; }

This is a series showing off news from the site, articles from the past month1, and fan-content for you to check out and discover! Be sure to leave a comment with your thoughts!

From the Editorial Desk -

Transparency in governance is something that we care a great deal about. We strive to showcase the vast majority of the actions Staff takes on 05 Command and in the deletions threads. Obviously, keeping track of every single minor change is impossible, the records-keeping side alone of such things would often take longer than the change itself. So while we may not keep track of every staffpost we make in the forums or every time a staff member adds a title or a rating module to a mainsite piece, we do record all of the major decisions we make on that site.

There has been a great deal of conversation lately about transparency, because it is also important to showcase the reasons behind why we make the decisions that we make. While this is not always possible due to a wide variety of concerns, we do strive to give rationale behind our decision-making process whenever possible. Additionally, there is a fine line between transparency and an outright invasion of privacy.

Our goal is to showcase the decisions we’ve made, why we’ve made them, and how we’re going about implementing them, but to do so in a way that doesn’t also impinge upon the privacy and mental health of the staff members who are volunteering to get the work done. While not all of you have had the opportunity to work in some sort of customer service capacity, a great many of you probably have. Those of you that have had that experience know first-hand how difficult it can be to maintain “retail mode” day in and day out. Even the most extroverted and genial of people can find themselves facing burnout when working through such a thing, which is why there are staff rooms and vacations.

The SCP wiki is a project that we all love and engage in on many different levels. While some users have found ways to monetize their usage of the site through youtube, podcasting, etc., staff members do what they do entirely without monetary recompense. We do what we do out of a love for the site and a love for the community that we serve. In that vein, we try to find a balance between doing what we can to adequately respond to the transparency requests of the general community, while also attempting to foster a healthy and fun work environment for the people that work behind the scenes to ensure everything keeps functioning properly.

We will always do our best to provide everyone with as much up front information as we can about what’s going on behind the scenes. In fact, the revamp of the Site News to become even more of a way to showcase the doings of staff is a part of that effort. Even so, we will not always be able to provide transparency in a way that everyone will appreciate. Every day we discuss ways to improve, and I ask everyone to be patient with us as we work towards finding that perfect balance.

The Site News team:
Editors: TSATPWTCOTTTADC & MalyceGraves
Reporters: Naepic, The Pighead, WhiteGuard, DrAkimoto, Edna_Granbo, Hexick, & Limeyy


Q: Can I replace a blurb that you wrote for one of my articles with my own? I'm not satisfied with it.

A: Absolutely. You will always have that option at any point.

Q: I noticed an error/typo/incorrect information and wish to correct it. May I?

A: Sure! If the changes are not limited to your own article(s) and/or are substantial changes across multiple entries, you should post in that month's discussion page and then make the changes.

Q: I wrote an article and it seems to have stuck. Can I send a blurb of mine to one of the reporters?

A: Yup! It's much easier if you come to us about it, and it gives you the control over what you want shown on the news page.

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License