in discussion Policy Discussion / Discussion Threads » Proposal: Amendment to CSS Policy
I default to Magnus here.
Recent Forum Posts
in discussion Policy Discussion / Discussion Threads » Proposal: Amendment to CSS Policy
in discussion Policy Discussion / Discussion Threads » Proposal: Amendment to CSS Policy
- Full support, although I fear the green/redlighting might be a strain on workload.
- I oppose any CSS theme that hides the translation module, as it is essentially a navigation tool in its own right.
- No objections.
- No objections.
in discussion SCP Wiki / Mainsite Staff Tasks » Guides and Essays - reorganizing
What you're proposing is redefining the current tags, which do precisely what people are asking for, to be more semantically pleasing.
I can't support that. Guide and Essay have always covered the same content, and it makes perfect sense to anyone who's read what the tag means. Not all tags are semantically consistent with their "obvious" explanation, and this is no different.
Your assumption is that guide is used for how-to guides only, which isn't really accurate. I understand the angle you're taking here, but that's not the purpose of essay vs guide as it's currently defined, and I don't see a compelling reason to add additional tags to accomplish the same task.
in discussion Policy Discussion / Discussion Threads » Proposal: Amendment to CSS Policy
No problem with any of this except possibly making sure we are clear in that hotlinking is restricted to use cases like font imports and not things like component images which should ride with the theme in the Files section, not some random jpg on imgur.
in discussion SCP Wiki / Mainsite Staff Tasks » Guides and Essays - reorganizing
I've got none!
Whether you like it or not, history is on our side. We will bury you!
in discussion Policy Discussion / Discussion Threads » Proposal: Amendment to CSS Policy
So long as Magnus approves of all these changes, I certainly have no objections.
in discussion SCP Wiki / Mainsite Staff Tasks » Guides and Essays - reorganizing
I'd really like to see the guide and essay tags being repurposed as what they describe rather than some arbitrary other meaning that should use another pair of tags.
I'm thinking that clear definitions for guide and essay skills be set out. A guide would be a page that explains how to do a specific thing. An essay would be anything else.
We wouldn't need an "official" tag if we just, say, labelled official essays/guides as such on the Hub.
Regardless of which option we pick in the end, I'd personally prefer to see tags in use that make sense for their purpose. If we're partitioning the pages by function, use guide and essay. If we're splitting by officialness, use official and something else. But I don't see the upside of mixing the two options up, and just because that's what we currently do doesn't mean it's good.
Just because something hasn't caused any problems doesn't mean it can't be improved
in discussion SCP Wiki / Mainsite Staff Tasks » Guides and Essays - reorganizing
Is this a thing that people have complained about? This feels very strongly to me like a solution seeking a problem.
If this is the case, I'm totally fine with cleaning up the Guide Hub without the introduction of new tags. Here's what I would like to see done though:
- archive the Essays Hub, since it's not used as far as I know.
- restructure the current Guide Hub so it includes a short definition of both "guide" and "essay" for new readers to refer to, and is better organized so far as listing everything goes
- make sure all pages tagged with "guide" and "essay" are on the Guide Hub
This is all stuff that I can do myself in maybe a couple of hours.
Does anyone have any objections to this?
in discussion Policy Discussion / Discussion Threads » Proposal: Amendment to CSS Policy
I am aware, I failed to articulate my point correctly. I was trying to say that despite the ability of the translation block to be modified, it cannot be altered fully to completely match a theme, and therefore removal remains reasonable. Roget asked why it was relevant earlier, I was attempting to partially answer that.
in discussion SCP Wiki / Mainsite Staff Tasks » Guides and Essays - reorganizing
I've been refraining from commenting on this proposal for pretty much the exact things Magnus has said above, but I hadn't found the words to do so. I don't think any of this is necessary.
in discussion SCP Wiki / Mainsite Staff Tasks » Guides and Essays - reorganizing
The distinction between an essay and a guide has always been that one is a user-created page without needing staff approval or consensus, and the other is one staff are saying is the "Correct" resource for that subject. "essay" pages have been promoted to "guide" generally, or have become official.
Overall, I'm not super hot about this entire proposal, but if everyone else is clamoring for it, I'm not going to stand in the way. I do not personally see the difficulty in understanding what is or isn't an official staff endorsed document, but that's my personal view of this. Is this a thing that people have complained about? This feels very strongly to me like a solution seeking a problem.
Here's what's going to have to happen by necessity if we add "official":
1) we need to go through all essays and find which ones are "guides" and re-tag them. I don't consider my "Advanced Formatting and You" a guide, for example. It's an essay with suggestions.
2) All pages that are "official" now get a second tag. So now they're official guides, or official essays. Can they be essays? This wasn't discussed from my reading, yet.
3) Is "official" only going to be applied to guides(/essays? see above) or are we now adding this to other pages? This has traditionally been the role of "admin".
in discussion Policy Discussion / Discussion Threads » Proposal: Amendment to CSS Policy
Removing the translation module has been part of the CSS policy since it was written.
Copied directly from the guide:
The translation module currently can't be altered via CSS. In the event that the Translation module clashes significantly, you are free to remove it via css, and maintain a list of translations in the comments section, or relvant hub for that article. Please try and keep it current to within a month at any given time.
in discussion Policy Discussion / Discussion Threads » Proposal: Amendment to CSS Policy
I would like to voice my full support for all of these, particularly the first point.
I attempted to import a font from a different site than Google Fonts, and it was considerably more difficult than Google Fonts, which makes the process simple and easy. Not allowing Google Fonts restricts users from an incredibly useful tool for little reason. Google Fonts is a reliable and trustable site, and many of the common concerns with hotlinking — Bandwith issues for the hosting site, licensing issues, and the possibility of the asset being moved — are not at play here. The biggest reason for not hotlinking is for the other site: if they encourage you to do so, that's not an issue.
The Translation block remains a weak point in CSS structure. It cannot be altered at present except through filters, which do not allow for a full range of alteration. It's difficult or impossible to get the translation block to look perfect, so being able to remove it should be allowed.
The other suggestions are good practice and provide strong benefits.
in discussion Policy Discussion / Discussion Threads » Proposal: Amendment to CSS Policy
All of these sound good to me, do we have any type of enforcement mechanism for CSS that doesn’t meet the requirements?
Also not really sure when removing the translation module would ever be necessary?
Whether you like it or not, history is on our side. We will bury you!
in discussion Policy Discussion / Discussion Threads » Proposal: Amendment to CSS Policy
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* |
| 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
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.
Shine on you crazy diamond o7
Good to know you, we're going to miss you but I wish you the best of luck in everything.
Going to miss you, Shaggy. It was good working with you. Take care do yourself.
in discussion SCP Wiki / Non-Disciplinary Record-Keeping » Non-Disc Record - DKQuake
User DKQuake made a couple of unauthorised minor edits to wording on SCP-358 and SCP-1717, twaddling the wording of the con procs of the former and adding an MTF name to the latter. I reverted both edits: probably not worth anything more than a light slap on the wrist here tbh.
Note that they also go by tomato-potato-mix in chat.
