Good Afternoon

After consulting with one of the Community Outreach captains, we agreed this would fall under the tech team.

There's been some talk about our CSS theme, and especially how to modify it, and what things within it, actually do.

To action this, tech team already has a project to comment our main wiki CSS theme. This will be done by Q2 of this year, in order to allow users to better understand how to modify the visual elements of the wiki.

This brings me to another question: What about custom CSS themes in use by the site?

There's been multiple issues over the past few months/years with CSS themes breaking/being broken by wiki elements, using themes, etc.

Therefore, I'd like to get together a policy regarding CSS themes, and formatting such as external CSS files. These are the things I could come up with regarding CSS Themes.

Use

Just like anything else on the wiki, a CSS theme must be licensed under the same Creative Commons site license, if it is hosted on the wiki. This means that anyone is free to use, copy, and alter that copy.

What they may not do is alter it for you. It would be treated like any other article or work on the wiki (minus being subject to deletion at this time. A deletion policy is not currently something I plan on pursue for themes).

What you can do:

Modify any colors, fonts, or visual components of the wiki that do not change their function or visibility

Alter the logo at the top of the wiki to a custom logo for your GoI/Canon/What have you

Add custom content that's relevant to your article, within the skrollr body of the article

Mess with other CSS properties such as spacing, collapsibles, what have you.

What you cannot do:

Remove, hide, or significantly alter any objects that are required for navigation.

Specifically, you are not allowed to remove components of the top or side bars.

Significantly alter the look of the wiki outside of the article content pane. Generally, keep your changes to the elements within the skrollr body of the article for major changes (other than colors/fonts or things listed above). Please don't put elements at the top of the page, in the way of the wiki header.

Use the final tag of a property to overwrite other properties on the requesting article. Your theme is yours, but other people can override parts on their page as they see fit.

Remove the rating module

Remove back/forward links from articles where they were created for.

Translation Module

There has been contention over the Translation Module in the bottom of the side bar, and not matching the theme's layout. I understand this, but many CSS themes are used by multiple people, and the translation block is used to give exposure to other international branches. Therefore, since it is a member of the side bar by default, you cannot hide it, on a theme being used on the wiki.

What you are required to do:

Comment your CSS them to provide users with reasonable direction to what a property does.

Existing css themes will have until 31 Dec, 2018 to add reasonable comments to their theme. What's reasonable? Explain what each section does, or affects. You don't have to explicitly define what a property does, but any reasonably intelligent author should be able to change the color of your header gradient if they wish.

This deadline also applies to the main wiki theme being used by the wiki. Tech team's on the job.

Not all themes MUST be hosted on the wiki, but if your theme is being used on the wiki, it is subject to the rules of can/cannot, detailed above. You do not have to comment your theme if it is not hosted on the wiki, nor are you required to make it publicly available at that point.

All staff are free to comment on this thread. I'm aware that users will feel strongly about this, and we should probably solicit feedback eventually. For now, let's see what staff feel about this.

What is missing here? What seems reasonable, or unreasonable? Let me know what you think.

As the creator and maintainer of two major CSS themes (one of which is the most commonly used alternative theme on the Wiki), I feel like I should weigh in.

I've gotta say, I am very much not a fan of this proposal.

First off, the section on things that wouldn't be allowed. Most of this just straight-up isn't necessary, because it can't be done with CSS. CSS can't be used to alter the structure of page, only its appearance, which means that it is impossible to remove rating modules, navigation links, etc… The best you can do is to selectively hide certain elements by making their background color transparent, but this doesn't work for a lot of things and it is in general not easily accomplished. The only situation where this rule would at all be relevant is the translation block — the issues of which I have addressed below.

Secondly, the prohibition on altering anything outside of the body of the article is… incredibly draconian, and precludes many things that are done by literally every theme currently extant, such as changing the wiki title, header bar color, sidebar colors, etc… Specifically, prohibiting the addition of elements to the wiki header makes it actually impossible to alter the logo or title, because that can only be accomplished with :before tags.

Banning the final tag is just bizarre, since it's essentially impossible to use two themes together in any way that makes sense, and there are legitimate cases where the final tag is necessary (chiefly because of poor coding practices in the original site CSS). (As an additional example of a use case for final though: actually making it possible to use two themes together. One thing I've been planning for a while is a set of sub-themes to be used over the base Third Law theme, and using the final tag on the sub-themes would allow me to apply certain sub-theme specific styling over the Third Law theme without duplicating all of the CSS from the main theme.) I basically don't see any legitimate reason for policing other people's coding styles, especially in a way that would preclude legitimate use cases.

Moving onto the issue with the translation block. I've mentioned this before, but the current implementation of the translation block is easily one of the worst ways of doing it, since it is loading a piece of the site navigation from offsite. As a consequence of this, it is impossible to apply any meaningful CSS styling to the block, and there are themes that have been around for much longer than the translation block that are broken as a result. Setting the block to invisible in the Third Law CSS was always intended as a temporary measure until a solution could be worked out, but despite promises from the block creators at the Russian Wiki that they would come up with a fix, no solutions have been forthcoming. Until such a solution exists, making the block visible again only serves to break the appearance of any articles using CSS that changes the sidebar color.

(I will note here that I don't particularly like have to hide the translation block, and am entirely willing to work with tech team and the Russian maintainers of the block to come up with solutions that will allow the translation block to be used with themes, or to come up with alternative implementations of its functionality that will work with themes — I even have a plan for how such a solution could be accomplished.)

Moving onto the last provision, this is the part that I am opposed to most of all. Mandating that every part of a CSS stylesheet be commented is creating an absurd amount of additional work for CSS maintainers, for marginal benefit. (Anyone with even a barebones understanding of CSS can figure out what different functions do just by reading the names of the selectors [because CSS is very verbose] and examining the stylesheet in their browser's inspector.) It is also, to some extent, impossible to accomplish, because the bulk of the style sheets is dead code from the site theme CSS that has to be included for compatibility reasons. (Most notably, all of the responsive CSS for the site's mobile theme — none of which is commented to begin with — needs to be included unaltered in every theme to get it to work on mobile. Despite not altering a single selector within this code, despite not being the one responsible for its original creation, despite having no idea how it works, I would be expected to produce comments on it.)

If the goal is to make CSS more understandable for people attempting to make a theme, comments on the default site theme should be more than sufficient. Again, I see no legitimate reason why tech team should be policing the coding practices of individual users.

TL;DR: This proposal is essentially an attempt to needlessly police the coding practices of individual members, and if implemented in its current form, would reduce every CSS theme to mere palette swaps of the background page color. As one of the less than half-a-dozen users with a direct stake in the outcome of this policy, I am strongly opposed to such a move.

I'm not actually sure what the point of this is, other than creating additional arcane rules to inspect and enforce, and artificial limits for content creators. Has there been an epidemic of custom CSS breaking site stuff significantly? Is this something that needs to be implemented to prevent further headache down the line?

I know there were a handful of issues when the navigation bars changed, but that seemed like a very minor hiccup rather than a serious issue. I'm not seeing the utility of having these regulated more than MAYBE something about staff reserving the right to revert custom CSS if it happens to break site functions, and after warnings and ample opportunity for the CSS writer to correct it.

It's largely about standardisation and making it easier for people to use themes as site resources. If themes are well-commented, most computer-literate but non-technical folks will not find it hard to modify/understand. It's standard practice with any code you expect anyone else to use or fix.

Most of it keeps it more easily reusable - it can't be easily overridden for one-off format screws if the the final tag is used, for example - and stops people from overriding important stuff. I do have a bit I take issue with, in my comment below.

Significantly alter the look of the wiki outside of the article content pane. Generally, keep your changes to the elements within the skrollr body of the article for major changes (other than colors/fonts or things listed above). Please don't put elements at the top of the page, in the way of the wiki header.

This should probably be changed.

I don't have a problem with a GOI theme saying "GOI name" instead of "SCP Foundation" in the top bar, and that is not currently provided for in these rules. Everything else here looks ok to me.

EDIT: I probably wouldn't have a problem with clicking "GOI name" bringing me to the relevant hub, if one exists, either.

This seems like a bit of an overreach on our part. This hasn't happened with a frequency that warrants the sudden, honestly draconian restrictions on it. "Fix your damn code if it breaks shit" seems like the necessary core piece, everything else seems excessive.

I disagree with a lot of this, and I say that as the person who is probably going to be commenting the base CSS theme.
The only prohibition that I agree with is not removing the rating module.
Also, furthering that, doing things like I have done on the rating module of my sandbox for ages:

This is not removal of the rating module but still manipulation of it to show a different number and is thus misleading.
I would recommend exactly two restrictions on CSS themes: they must not be malicious in their implementations and they must not decieve users with regards to the operation of the site.

Forbidding the final tag is weird because users can just make their own copies of existing CSS themes which don't use the final tag in those places.
I strongly disagree with there being any imminent or non-imminent need to comment every existing CSS theme, nor any reason to force users to comment their own.

Agreeing that this feels like a serious overreach. The only obviously necessary part of this is disallowing removal of the rating module, but that's already been a separate rule for years. I would also be on board with Randomini's suggestion.

I am not Technical, nor a subject matter expert, so I am open to further arguments in favor. However, based on reading all of this thread, I strongly oppose this move at present.