Link to article: CSS Policy.
.policy { border: 1px solid #ddd; padding: 1em; margin-bottom: 1em; }
policy
The following policy concerns CSS themes, primarily those that are self-contained and may be imported onto other pages, but much of this policy also applies to embedded CSS on individual pages. [[module CSS]] .policy { border: 1px solid #ddd; padding: 1em; margin-bottom: 1em; } [[/module]] [[div class="policy"]] + Creation A CSS theme should be drafted on a sandbox page. Once you feel the theme is ready, you may move it to the Wiki proper. Once you have recieved permission from a member of the Tech Team ([[[chat-guide|#site11 on IRC]]], or on [https://discord.gg/84bZrPnrMg Discord]), who will make sure that your theme is compliant with this policy, you may create a new page on the wiki in the {{theme:}} category with the {{theme}} tag. Some older themes have been posted to the {{component:}} category. Please use the {{theme:}} category. The theme must be compliant with the following restrictions, listed below. [[/div]] [[div class="policy"]] + Restrictions In order to be allowed on the site, there are a few restrictions that your theme must abide by. **Licensing** The theme must be released under the same Creative Commons license as the rest of the wiki. **What you can and can't change** You may change any of the style components of the wiki other than stuff that's specified in this policy. You can't remove, hide, alter, or "break" any navigation elements of the wiki, or the rating module, or the [[[component:adult-content-warning| Adult Content Warning]]]. You can't break the structure or look of the wiki beyond realistic expectations. The site should still be recognisable and readable. You can style the translation module (.scpnet-interwiki-frame) using the [[[component:interwiki-style|Interwiki Style]]] component. You are not allowed to alter or remove its contents. **Basic functionality** Your CSS theme must work well in the major browsers (Chromium, Firefox, Safari) and be at least functional in minor ones (IE 11 etc). Your CSS theme must work well on mobile as well as desktop. **Setting up the theme's page** The theme's page is where the source code of your CSS theme is kept. You must instruct users to add your theme to their page using Wikidot's [[include]] method (and set up your theme page accordingly. [http://scp-sandbox-3.wikidot.com/css-include-template Here's a template]. You may not instruct users to add your theme to their page via CSS's {{@import}} method.[[footnote]]If you see a page that uses a theme via the @import method, and an [[include]] method is available for that theme, you may edit the page to update it to the new method.[[/footnote]] You may not instruct users to use any Wikidot syntax which uses HTTP links, they must be HTTPS. You must provide usage instructions on your theme's page. Note that this only refers to telling users what to type to get the theme to show up on their article. If your theme has any special features that an author should know how to use, these must be documented as well. You do not need to include examples of your theme's formatting -- although you totally can, and definitely should! Your theme's page must have your theme applied to it -- i.e. your page must act as a preview of your theme. If you used the template linked above, this will be done for you. The Tech Team member who's approving your theme will expect to see not only your CSS source code, but a draft of your theme's page. **Bloat code** A CSS theme cannot contain huge amounts of code that doesn't do anything. A CSS theme's source code should contain little, if anything, other than what this theme changes from Sigma-10 (the wiki's base CSS theme). Vast sections copy-pasted from Sigma are strictly not allowed. Someone familiar with CSS should be able to look at your theme and know exactly what your intent is. At the very least, you should be able to justify why you have chosen to include any given line. Additionally, you should try to avoid using the {{!important}} marker unless you really need it, e.g. to provide compatibility with other CSS where [https://developer.mozilla.org/en-US/docs/Web/CSS/Specificity increasing the specificity] would not suffice. **Accessibility** Accessibility concerns should be considered when composing a CSS theme. For example: * Is this theme readable for colorblind people? (e.g. it employs bad color combinations like red + green which make it difficult for colorblind users to navigate the site) * Does this theme hamper the ability to use screen readers? (e.g. it adds 'invisible' content which gets read by screen readers but not sighted users) * Are the fonts it uses legible for all users? (e.g. the body font size is too small, the font itself is difficult to read) * Could the theme induce a photosensitive epileptic seizure? (e.g. it has rapidly flashing colors or alternating patterns) If so, these elements must be removed. and so on. Best practices and recommendations to address all of these potential issues are easily available with a cursory Google search. **Hotlinking** Hotlinking is the practice of linking to files on another site, and is both incredibly bad practice and against site rules. It is incredibly bad manners to force someone's site to load images for your theme, and also introduces a degree of unreliability to your theme -- what if that site disappears? To prevent hotlinking, all images, fonts and miscellaneous files used in a CSS theme must be files uploaded to the theme's page rather than linked from elsewhere on the internet. However, you are permitted to use certain sites that explicitly encourage hotlinking for serving files to users. Notable examples include [https://fonts.google.com/ Google Fonts] and [https://picsum.photos/ Lorem Picsum]. If in doubt, play it safe and [[[chat-guide|ask the Tech Team]]]. Additionally, CSS may not be linked from sandbox pages or anywhere that isn't the main site (outside of workbenches). You must use a {{theme:}} page on the wiki for CSS themes. **HTTPS** Your CSS theme must be completely functional on the HTTPS version of the site (https://scp-wiki.wikidot.com/). This means any internal {{@import}}s or {{url(...)}} references must refer to HTTPS URLs. For Wikidot, this means that the link takes the form {{https://scp-wiki.wdfiles.com/local--files/SLUG-OF-PAGE/FILENAME}}. Note that HTTPS wdfiles links work even on sandboxes without general HTTPS support. **Approval** Before being posted, your theme must be approved by a member of the Tech Team. They will take a look at your theme and ascertain whether or not it is compliant with this policy. You can find the Tech Team in [[[chat-guide|#site11 on IRC]]], on [https://discord.gg/84bZrPnrMg Discord] or via [http://05command.wikidot.com/technical-staff-main Wikidot PM]. Only Operational Staff and up can approve a CSS theme. The Technical Team Captains get final say in any approvals. Members of the Technical Team must get themes they created approved by another Technical Team member. An approval from the Tech Team comes with the expectation that your theme will be posted in the next few days at the latest and with only minimal changes; if you are posting a theme long after getting approval or if you've made major changes, please re-seek approval. Be sure to give the Tech Team plenty of time (i.e. a couple of days) to look over your theme. [[/div]] [[div class="policy"]] + Deletion policy for CSS themes CSS themes are treated like normal pages in that other users are not permitted to make major changes to your work. Small mistakes are considered equivalent to spelling and grammar errors and may be corrected by any well-meaning user. CSS themes are affected by the regular deletion policy, and are eligible for deletion once they fall under -10 votes. [[/div]] [[div class="policy"]] + Remediating non-compliant themes If your theme doesn't function in the major browsers (Chromium, Firefox, Safari, mobile, IE11) in a way that completely breaks navigation, function, or accessibility, it needs to be **removed** (or at bare minimum, removed from include blocks) from the site, then fixed, in that order. Our first priority is compatibility, function, and accessibility. [[/div]] [[collapsible show="+ Approval Checklist" hide="- Approval Checklist"]] This list is written for Tech Team members who are approving a theme, although theme creators may find it helpful. ++ Requirements The theme must be able to answer "yes" to all these questions. # Is it clear what the theme does? # Is the theme applied to its own page? # Does it appear to work? Is it free of obvious errors? # Does it work on mobile? * A common mistake is to use {{background}} (with an implicit {{background-position}}) to change the header logo, which removes all the mobile positioning, instead of {{background-image}} which only changes the logo image. Does the theme achieve its logo change (if any) appropriately? # Does it work on another browser? (try Chromium and Firefox at minimum) # Are the navigation components all present and ok? * If the theme targets {{#login-status}}, check to make sure a message notification is still visible * Is the main header still a clickable link to the front page? # Does the page still look like the SCP wiki? # Are there English usage instructions? # Is the page using {{[[include]]}}? # Is there a lot of bloat code? (e.g. large sections copied from Sigma-10 or other themes) (if in doubt, ask the author to explain what a section is for. If they can't, it's likely bloat) * Check imported files and fonts (including fonts of different weights), are they all used? * If the theme is a fork of another theme (meaning the code has been copied and edited as needed), is the creator able to justify this? * Have they considered extending that theme instead (meaning including the theme, either into the theme itself or by asking the end user to include it, and then overriding what is needed)? * **Strongly** prefer extending where possible, to minimize code duplication; there should be a very good reason to fork * If the author insists on forking, can they explain why? Can they demonstrate that they are skilled enough in CSS to understand and maintain any complex features they have copied? # Is the CSS easy to understand? Where there are complicated parts, are they difficult commented? (there should be no parts that you don't understand AND the author can't explain) # Is the theme free of any accessibility issues? (Themes must be at least as accessible as Sigma-10 -- they must not introduce further issues, but are not responsible for fixing existing issues) * Is the font size too small? * Is there any text that doesn't meet [https://webaim.org/resources/contrastchecker/ contrast recommendations]? * Are all motion-heavy or repetitive animations gated behind a [https://developer.mozilla.org/en-US/docs/Web/CSS/@media/prefers-reduced-motion prefers-reduced-motion] check? * Are important elements e.g. links clearly distinguishable? * Is the page source panel readable? This area is often forgetten because it's under an options menu. * Try tab-navigating the page, are interactive element (links, sidebar, topbar, main header link, searchbar, page history buttons, etc) visually differentiated when they are focused? * Most browsers use the {{outline}} property for this; where the outline has been removed/overridden, check that alternatives have been provided * Do all fonts have a fallback font defined? * Is there some visual information other than cursor shape and text color to tell when a link has been hovered? * Highlight some text; is the highlight visible? * Check a couple of more complex UIs e.g. page history and page edit, are they okay as well? * (list any other common accessibility concerns as they come up) # Are changes to built-in elements echoed to the duplicate elements provided by Sigma? * Are changes to {{blockquote}} also applied to {{div.blockquote}} (sic)? [!-- sorry -aismallard --] * Are changes to {{#page-title}} also applied to {{.meta-title}}? * Are changed to {{#breadcrumbs}} also applied to {{.pseudocrumbs}}? # Is {{!important}} used reasonably? (a few uses are ok, none is ideal; ideally any uses should be documented) * {{!importants}} relating to the rating module are probably fine # Ctrl+f for http, are all external resources hosted on Wikidot? # Does the theme work on HTTPS? Does it have any resources loaded over HTTP? # If the theme provides any custom functionality, is its usage documented? # Is the theme compliant with the CC BY-SA 3.0 license? * Are all images used compliant with CC BY-SA? (this includes embedded images e.g. inline SVGs) * Are all fonts used compliant with CC BY-SA? (Google Fonts is fine, but check other providers and/or custom uploaded fonts) * If the theme uses an organization's assets or reproduces it in some other way, is it compliant with their licensing practices? # Is the theme compliant with the [[[Technical Content Policy]]]? * Are any file assets a reasonable size? # If the theme is a dark theme, is the background of the root element set to a dark color? (this will inform browsers that the theme is a dark theme, and set scrollbars etc accordingly) * This is not necessary if the theme extends an existing dark theme that already does this ++ Non-Requirements If the theme can't answer "yes" to any of these questions, offer advice on how to improve it. They are not required for approval. # Is the code clean and easy to understand? # Is the CSS properly indented, and are the comments consistent? (these can be indicative of mass copy-pasting) # Does the theme look good? # Is it clear what the theme is for, and who should be using it? * The term "aesthetic theme" is commonly used as meaning 'not associated with any in-universe premise or canon'; if this theme uses that phrase, is it consistent with that meaning? Could it be more explicit? # Is the documentation clear? * If there are examples, are they meaningful? * If there are examples of things that are unchanged by the theme, could they be removed? ----- After approving a theme (or component), notify the rest of the Tech Team, even if the page has not yet been posted to the wiki. Checklist for posting an approved theme to the wiki: * Theme is posted to the theme category * Page is tagged theme (and _image if there are any images) * All file assets are ported to the wiki * File assets are linked with https, not http * Co-authors are logged in [[[attribution-metadata|]]] * Tech Team member who approved the theme leaves a comment on the page to indicate as such (after giving the author a chance to post the first comment) ----- **Recent Themes** [[module ListPages limit="5" category="*" tags="theme" orderBy="date desc" separate="no"]] # %%title_linked%% by [[*user %%created_by%%]] on %%created_at%% [[/module]] [[/collapsible]]