I'd like to propose four amendments to the CSS Theme Policy. Policy here, discussion here.
1. Allow certain hotlinking
Hotlinking is incredibly bad practice and also against site rules. There isn't a good reason to do it, given that you can host assets such as fonts on the page itself, and it also introduces problems when browsers prevent CSS themes from accessing off-site resources. As an example of how this breaks, was a version of a new rating module hosted on the sandbox. Users reported them breaking because their browser would block the page from loading it entirely.
Hotlinking is generally bad practice, particularly for large image files, but sometimes it's the best option. Google Fonts is a resource that lets CSS themes import fonts effortlessly. Manually creating font files is a pain in the bum, and not all browsers support all formats, yet our CSS policy currently requires that we do this. Google Fonts would make that process easier for the CSS developer - and make page load times faster for the end user, too. Google Fonts is both faster and more reliable than Wikidot. As if on cue to demonstrate my point, Wikidot failed as I was creating this very thread: https://i.imgur.com/4lwXTtx.png
Even sigma9 uses Google Fonts.
I'd amend the policy to specifically exclude tools that require hotlinking for use. This would include Google Fonts, and other tools such as Lorem Picsum - no more come to mind currently, but there are definitely many out there. Blanket-banning hotlinking prevents CSS writers from using these tools.
2. Translation module inaccuracy correction
The translation module currently can't be altered via CSS.
It totally can. This is the CSS used by MrPines' Prometheus Labs Theme to change the translation module from red to blue:
.scpnet-interwiki-frame {
filter: hue-rotate(260deg);
}I'd amend the policy to remove the inaccurate statement, but maintain that CSS writers can remove the translation module if they must, with the same requirements.
3. Provide usage instructions
No software is any good if the end user doesn't know how to use it. CSS themes are no different. Without usage instructions, they're just random lumps of code.
I'd amend the policy to state that all themes must provide usage instructions for authors looking to use the theme on their article.
4. Use [[include]], not @import
There are two methods of getting a CSS theme onto a page - [[include]] and @import. Most themes, particularly older ones, use @import. Some newer themes use [[include]], and there are clear benefits to doing so. I've outlined the differences between the two in this table:
| [[include]] | @import |
|---|---|
| Slightly more difficult to set up | Slightly easier to set up |
| Slightly easier for writers to add to their articles | Slightly harder for writers to add to their articles |
| Ability to provide usage instructions on the theme page | Ability to provide usage instructions on the theme page* |
| Can show examples on the theme page | Can only show source code on the theme page |
| Lets you see a list of pages that use the theme | Does not create a list |
| Lets you send both CSS and HTML to the themed page | Can only send CSS |
*: It's worth noting that while the @import method allows CSS writers to provide usage instructions, no themes that use @import currently do so except the Unusual Investigations theme (which, ironically, also requests that nobody uses it)
As an example of the [[include]] method, see the Pataphysics Theme. Head to the bottom of the page, click +Options then Backlinks. You'll be presented with an automatically-generated list of pages that use this CSS theme. Someone updating the CSS can look to these pages to see what, if anything, could break when the CSS is updated.
As an example of the @import method, see the SPC Theme. Scroll down and open the Backlinks. There's no way of telling which pages use this theme, so no way of telling which pages could break if it's updated.
To clarify: [[include]] is good because it generates a list of pages that use a theme. @import is bad because it doesn't do that. A CSS theme can support both, and changing @import to [[include]] is easy from the CSS developer's perspective - myself or someone else who knows how to do so will be more than happy to provide instructions.
I'd amend the CSS policy to enforce using [[include]] over @import on new CSS themes, and that existing CSS themes should also be changed to support the [[include]] method. For existing CSS themes, however, removing the ability to use the @import method would break existing pages, so both methods should be supported.
Please post any and all thoughts both for and against the 4 proposed amendments.
I see no reason to exclude JS from this discussion.
Discussion will be open for 7 days with opportunity for an extension if debate is ongoing.