Modifications to style preserver userscript

Hey, Croquembouche here from the wiki. I'd like to suggest a few changes / best practices implementations to the style preserver userscript.

Most important thing is probably to get versioning set up correctly - this'll enable userscript plugins to detect when changes are made to the userscript and to prompt the user to update them. At the minute, without a version field, users likely won't ever be aware of any updates you make. (Tampermonkey docs)
It's generally a bad idea to bundle large external libraries like jQuery into small scripts like this - at the minute it's probably something like 90% of the file size. Standard practice would be to import it from their CDN, but Wikidot contains its own copy of jQuery that you can call anyway.
jQuery is old. The stuff that it was designed to achieve was useful a decade ago but these days most of that can be achieved by the browser. It still works, obviously, but it's not necessary and I wouldn't use jQuery in any new projects. So despite Wikidot already containing it, I'd avoid its use altogether.
The waitForKeyElements function looks like it's been pasted from somewhere. Without a source, it's not possible to tell what licence it was released under. Unless you know otherwise, we have to assume that it's copyrighted, so distributing a userscript that contains it is potentially legally problematic.

Then there's a couple of functional changes that I'd like to make:

I don't think the script needs to wait at all. I'm pretty sure Wikidot inlines the style elements directly into the page on the server, so just having this run on the DOMContentLoaded event is probably fine. We wouldn't need to wait for this event, because it's the event that userscripts run in anyway.
It'd be real nice if there were a way to detect whether styles are actually themes or not, to avoid breaking visual styles elsewhere. I'm not sure what the best way to do this would be, if any.
- Any styles that just import CSS from the theme: page category can be blocked. Not all themes do this, though - some inline their CSS directly with no @import. There's a couple of other disadvantages to doing this, so maybe we (the tech team) can look into prohibiting themes from doing that - if we can, then there shouldn't be any problem detecting theme-only styles (on SCP-EN, anyway).

After my proposed changes, the userscript would probably look something like this (pseudocode for now):

for styleElement in styleElements:
  if isTheme(styleElement):
    styleElement.remove()

I'm totally down for making a pull request to implement some of these changes at some point, but unfortunately I'm really busy at the minute, so I'm just making an issue to note down my thoughts. Would love to hear yours!

Hi!

Let me go through the best practices stuff;

Version field is actually accounted for (see: https://github.com/noirscape/dotfiles/blob/master/userscripts/sigma9preserver.user.js#L4 ). What you are referring to is updateURL, which is meant to be used for scripts which have hundreds of thousands of users (in which case it becomes useful to set updateURL to a .meta.js file that contains only the metadata block while setting downloadURL to the actual .user.js file. (See this SO issue for details). I highly doubt that GitHub can't deal with that workload, and worst comes to worst I can push an update to take care of that.
jQuery: Honestly, I mostly picked it because it's what I was familiar with when it came to selecting items from the webpage. I should probably get rid of it, but I got really annoyed with getElementsByTagName, so I used what I was familiar with. I might take out jQuery out later, I prefer the smaller solutions anyway. Wikidot's jQuery is loaded in through it's ad network (onesignal). That makes it unreliable for users with adblockers.
- I inlined it because of this recent fine in the EU that has made me wary of bundling resources that link to stuff I have no full control over into the things I make (which, considering I fall under EU jurisdiction makes it a concern).
waitForKeyElements is from this gist and was released into the public domain here as CC0 (more aggressive than your typical "WTFPL" dedication, since those aren't always strictly legal).

Next, about the functional changes:

About DOM event: I couldn't get that DOM event (I tried this at first) to fire properly on my end with Greasemonkey, so I used the helper function instead.

About theme detection: You'd think so, but the reality is that there really isn't a standard way to import style elements from what I can tell; some pages use clean @import calls to stuff on wikidots namespace itself, but others do not.

To take an example; Black Highlighter (test case: SCP-049), which is multiple import calls to GitHub pages, all spread out across several smaller components.

Therefore, the only reliable way to detect themes seems to be to simply scan for any <style> tag inserted by the browser that has no ID (since the CSS module doesn't seem to allow setting those, and Wikidot adds IDs to it's own and the site theme) and unloading it from the DOM.

I'll probably try to get rid of jQuery and see if I can get DOM events actually working, like I said, JQuery was mostly picked because I knew how it worked and the helper function I used also used it which was a lucky concidence.

As for the other functional changes, unfortunately this appears to hit the limitations of wikidots own CSS module. The easiest would be if the CSS module were to set it's own class property on every style it adds, that way you could just scan for those and pop off anything that isn't set by Sigma-9 (which is loaded with the ID internal-style) (the absolute cleanest would be to give every style the id property thats set to something like cssmod-pagename, but at the moment this does not seem to be possible.

Those are my thoughts at least; looking forward to hear some of your suggestions.

Versioning: This is going to sound really dumb - I was looking for a version of the form vN.N.N, missed the 1 entirely. Sorry! I didn't mean to imply that you didn't know what you were doing regarding this.

That's good to know re updateURL and downloadURL. In the past I've always just brute-forced it and set both to the script URL. Thanks for linking that SO answer. Interesting to learn that Greasemonkey specifically doesn't require @version at all for auto-updating, technically.

jQuery: Wikidot does ship its own jQuery in init.combined.js, v1.11.3. It's exposed to the window as jQuery and $j (but not $).

The OneSignal stuff could well include jQuery as well, no idea, I have it blocked :)

Regarding inlining vs linking, I agree with your justification and I also prefer inlining - but I prefer not having dependencies in my source code more. So I'll inline during a bundling step if I have a build process, and link from a CDN if I don't. This userscript (and all of mine) doesn't have a build process, so in this case (ignoring that Wikidot comes with jQuery) I'd CDN it.

As an aside, I realise now that my concern about filesize is literally not an issue at all, because this userscript will be saved on the client, not re-served on every page.

DOM events: Yep, a userscript won't catch the DOMContentLoaded event, because that's the event that initiates the userscript. As a result here's a minimal working example of a theme remover, no event listener needed:

Theme detection: Yeah, frustratingly, there doesn't seem to be any way to distinguish CSS modules beyond their content. It would be real nice if Wikidot attached even a data-css-module-source-page attribute or something.

My concern about being too eager with the selection is when it comes to functional components. For example this currently breaks both the info module and nested collapsibles - here's the effective info module for example:

The only reliable way currently does seem to be the catch-all for all inlined styles, which necessarily breaks every article with custom styling (SCP-5999 is adorable). However, as a style blocker, this approach does work shockingly well for most pages. The nested collapsibles being opened by default could even be considered a bonus.

Hey! It's been a year or so and while I've been extremely busy the past year, I have tested your changes and they appear to work fine; I've currently pushed a reduced version of this userscript that uses querySelectorAll instead. I understand that while my version did almost certainly work, I still don't relying on loading in the entirety of jQuery.

Part of the reason I've been busy for the last year has involved getting browsers running in low-power environments and this has kinda made me realize that if you can rely on it without needing to polyfill (which jQuery pretty much is nowadays).

As for the goal of blocking styles - yeah I don't consider this stuff being folded out a negative. I'm a big fan of keeping webpages simple and easy to read. SCPs are mostly (in my experience) text-based so unloading the styles is a good way without having to resort to the oft-browser specific Reader mode (which leans in the other problem direction of stripping out way too much).

Sigma9 is a beautiful theme for consistency's sake (plus it hankers back to a time I am unreasonably nostalgic for :p - it's very much a desktop theme made responsive instead of a mobile theme that was blown up to fit on a desktop, which is something I enjoy a lot since I tend to read a lot on a desktop) and it can be quite jarring to suddenly switch to a different theme when reading a page, especially when some of these themes move a lot of interface elements around (of which Black Highlighter is a remarkably consistent culprit - no offense to the designers, with the exception of some of its animations I actually quite like the idea, its just quite jarring as a reader).

Ideally wikidot would just allow better page theme selection (ie. allow a visitor/user to just select the theme they want across the site) but it's aging software so I understand why this isn't the case. For me, sigma9 works fairly well on that end and this method, while not by any means perfect does the job. 5999 is indeed very impressive work in terms of what it does, but at the same time the page breaks so blatantly that it becomes obvious to me that "hey, I should turn the userscript off". I am not on a war here with custom theming if it improves the article - for me the intent was always to be able to quickly toggle it "as needed".

noirscape / dotfiles

Modifications to style preserver userscript #1