IMPLEMENTED: http://www.scp-wiki.net/css-policy revision 4
It's been a hot minute since the last time I tried to pass an amendment to the CSS policy. Here we are again, with some amendments that are the same, some that have changed, and some new ones.
Links:
The last amendment did not pass because there was some disagreement about timeframes. The time spent between that proposal and this one doing nothing has determined that my initial pressure to get stuff done quickly is irrelevant, and has now been resolved.
In the following sections I will lay out 11 amendments to the CSS policy that I believe are improvements. To cut through the bulk, I have bolded the actual policy changes. The rest is context and explanation.
There's a theme here of short-term awkwardness as the price for long-term improvement. I think it's a little overdue.
Amendments are as follows, with the long ones collapsed for your convenience.
1. Allow certain hotlinking
Hotlinking will be allowed from sites that encourage it, for example Google Fonts.
No changes from last time
2. Translation module inaccuracy correction
The policy will be corrected in that the translation module can be affected by some CSS.
No changes from last time (barring changes from Amendment 6, see below)
3. Provide usage instructions
CSS themes must provide usage instructions. (They don't need to include examples.)
No changes from last time
4. Use [[include]], not @import
New CSS themes must use the [[include]] method, not the @import method. Existing CSS themes will be changed to support it, if they don't already.
Same as last time, with the following additions:
- CSS themes both old and new will no longer be allowed to advertise the @import method
- Articles that use @import for native scp-wiki themes should be (eventually) changed to use [[include]]. This will be considered SPaG and may be changed by any well-meaning user.
See the old proposal's thread for an in-depth explanation of why [[include]] is better.
5. The theme must be applied to the theme page
The CSS theme must be applied to its own component page, making it trivial for an author to see what that theme looks like without having to find or create a page that uses it.
6. Keep the translation module
CSS creators will no longer be allowed to remove the translation module. It remains the most important tool for cross-branch navigation.
7. A theme must be used by at least one article
A new CSS theme may not be posted unless it satisfies one of the following:
- It will be used on a pre-existing article.
- It is being posted alongside an article that uses it.
- It is being posted shortly before (~1 week) an article that uses it.
A CSS theme that is not being used by any articles will be removed, regardless of age.
I see no reason to have CSS themes on the site that aren't associated with any page. We're a writing site, not a CSS repository.
Additonally, the decision made in this thread should be mentioned in the CSS policy document.
8. Themes must not contain an excessive amount of bloat code
A CSS file is a list of rules that a webpage must obey. sigma9, the site's base CSS theme, is such a list of rules.
All CSS themes on scp-wiki.net are being applied in addition to sigma9. As such, any rule in a new CSS theme that is the same as a rule in sigma9 is unnecessary. A theme that is mostly made of such rules is very difficult to read, as it's near-impossible to know what the CSS creator has changed.
A well-written CSS theme would only be the rules that have changed. As a result, simple themes that only change the logo and a few colours here and there should be very, very short.
This amendment proposes that all CSS themes, pre-existing and new, must not contain an excessive amount of bloat code. It should be easy for someone familiar with CSS to see what the theme achieves. The CSS creator must, at the very least, be able to justify any CSS rule in their theme.
9. New themes must be approved by a member of the tech team
All new CSS themes must be approved by a member of the tech team (OS and above) prior to being posted.
A CSS theme that has not been approved will be removed immediately. CSS themes that predate this amendment will not be affected.
CSS authors may seek approval for their theme as many times as they need, provided they have made the appropriate changes to comply with the CSS policy.
This is mostly a formality to make sure that any new CSS themes do not violate the policy.
Tech team members are advised to be lenient on approving themes. "I don't like it" is not a valid reason to disallow a new theme. If a theme is disallowed, a specific part of the CSS policy must be cited. Tech team members may defer to a more experienced member of the team. A tech team member may ask to see a draft to ascertain compliance with Amendment 7.
If there's a problem, Tech Team Captain gets the final say, overridable by admin contact.
10. Existing themes must be changed to comply with the CSS policy within six months
Last time, I suggested that themes must be changed within two weeks of the amendment passing, after which a member of the tech team would make the changes.
At the time of writing it's been 262 days since the timer for that amendment's discussion ended. I don't think time is a concern.
This amendment proposes that all CSS themes must be changed to comply with the new CSS policy within six months. After this point, the tech team will be granted the authority to make those changes. The CSS creator may then modify those changes to their liking, provided that the result remains compliant with the CSS policy.
11. Themes should be posted into the theme category
Themes are currently posted into the component category. They should be posted into the theme category.
New themes will be posted into this category.
Existing themes, eventually, will also be moved into the theme category. This change of URL will break all pages that use a theme - as a result, this change should not be implemented until at least after the theme has been changed from @import to [[include]] per Amendment 4.
For now, new themes will be in the theme category where they belong, and legacy themes will remain in the component category until it is convenient to make the change. This will take at minimum six months (per Amendment 10) and will likely take far longer. For now, they will exist in two categories, although the theme tag will still exist to link them together.
Please post any and all concerns and discussion. Discussion will be open for 7 days with opportunity for an extension if debate is ongoing.
