Ideas

[Mottie]

Issues to be addressed:

• Wrap icon hover colors (mentioned here).
• Fix checkbox style in Firefox.

---

Implemented:

• Fix input[type=number] style in Firefox.
• FOUC - I still can't get @run-at document-start to work consistently.
• Not working on gist pages... the @include is copied straight from GitHub-Dark so I don't know why it's not working.
• Add docs - https://github.com/StylishThemes/GitHub-Dark-Script/wiki.
• Install theme using sub panel.
• Change background image.
• Change link colors.
• Change syntax highlighting theme.
• Change code font.
• Toggle style on & off (but make it work in Firefox).
• Toggle wrapping of long code.
• Use local storage to save all settings.

---

Ideas for the future:

• Add keyboard shortcuts:
  • Open the GitHub Dark options panel.
  • Toggle style on & off.
• Change syntax highlighting separately:
  • GitHub.
  • Ace CodeMirror editor.
  • Jupyter.
• Change font style & size:
  • Site.
  • Code.

[silverwind]

Two issues with style installation and likely theming:

1. A Stylish style with !important rules can't really be overridden from a content script. We might have to require the user to uninstall the userstyle first.
2. Certain styling in Firefox like checkboxes won't work from a content-style. AGENT_SHEET currently elevates our stylesheet to a user agent style which is able to style the Shadow-DOM.

[Mottie]

I was thinking that we could add an "override" to styles... like maybe define a block like this:

body:not(.customized) .something { color: red !important; }

then when we add a custom style, add a "customized" class name to the body.

[silverwind]

That'd of course work, but you'd have to add body:not(.customized) to every single selector I assume. Not practicable I guess, except for the few things we want to be toggleable.

[Mottie]

Ugh, you're right... ok, we can just do what we do with grunt. Add some extra comments at the start & end of blocks we want to remove...

/* grunt-remove-block-below */
...
/* grunt-remove-block-above */

I ended up using this method in the Stackoverflow style... here is the grunt replacement:

// remove default syntax theme
pattern: /\s+\/\* grunt-remove-block-below (.*(\n|\r))+\s+\/\* grunt-remove-block-above \*\//m,
replacement: ''

[silverwind]

I think the approach with the body classes is fine as long as we only toggle a few select things. We just can't do a full style replacement for above reasons.

If only we could access a userstyle through things like document.styleSheets, but I guess the security model of the browser won't allow that.

[Mottie]

Oh, I thought you said we could load the "github-dark.css" file using GM_xmlhttpRequest. Then we could process and add it to the stylesheet using GM_addStyle... or am I wrong?

[silverwind]

We could do that, yeah. My point is, as long as the userstyle is loaded, it will interfere (in terms of style weight) with any style we add to the page. Class toggle seems the only way to go I'm afraid.

[Mottie]

I've been working on a basic structure.

So far I have this idea for the script sequence:

• Load the GitHub-Dark package.json
• Compare the version number saved in local storage to package.json version.
  • If older, load github-dark.css & process
  • If the same, process stored css
  • I've been thinking about only loading the package.json once a day, and we can add a button on the GitHub-Dark panel to force an update, if needed.
• Process base script using string replacement methods for colors, background, etc.
• Update stylesheet (I plan on adding a <style> tag to the DOM which we can update, instead of using GM_addStyle)

If the user chooses a different setting, the script will need to load in a new syntax theme (if needed) and trigger the Process function again.

[silverwind]

Sounds good. It's certainly is easier to maintain than a class toggle (and more flexible). The drawbacks are likely these:

• Styles that rely on AGENT_SHEET (I only recall checkboxes) won't work in Firefox
• Users need to uninstall the userstyle

You could do the update check by writing saving a timestamp and then check if at least 24 hours passed.

[Mottie]

Ok, I've pushed a very basic setup to the master...

It still has a few issues that I was going to work on today, but some things have come up, so I thought I'd at least share my progress:

• Hmm, I had that enable checkbox working last night...
• Theme selections don't appear to load, I can get a debug log to show, but it's empty.
• I'm not sure what to do about the page load delay. It sure takes a lot longer than Stylish to apply the theme.
• I can't get the color picker script to initialize. I "think" it loads, but never applies.

Please feel free to make whatever tweaks or adjustments you desire.

[Mottie]

Added some more tweaks, the silly enable checkbox still isn't working - ugh.

I forgot to mention, if you add ?debug to the url, you'll start seeing messages in the console.

[silverwind]

Made a few tweaks. Here's the deal with the loading delay:

There's @run-at which can make the script execute before the site's own script when set to document-start. I added the default document-end to our metadata block. I think it's necessary for good performance. To make it work, It may be necessary to use GM_addStyle, I'm not sure yet if the HTML is there to add our style tag when this loads. Oh, and you definately have to disable the check for the options dropdown to make it work.

You can actually load both JS and CSS from metadata blocks like this:

// @require     https://url/something.js
// @resource    something https://url/something.css

And then apply the named style:

  GM_addStyle(GM_getResourceText("something"));

The benefit of that method is the Greasemonkey loads and caches scripts/styles each time the script itself is updated. Greasemonkey also does a daily update check to @updateURL so I think that should be enough. Seems better to go this route than write our own update mechanism I think :)

I'll leave changing that up to you ;)

[silverwind]

Oh, and by the way: It's nice for userscript development if you symlink the script from your git repo to the browser's storage directory (works in Firefox at least, as it just stores the script under gm_scripts in the profile folder), so you don't have to do any copying. There's this for symlinking on Windows.

[silverwind]

I'm thinking we should apply the style asap on document-start and then wait for jQuery's ready event to add the option menu.

[Mottie]

Sounds good... I'll include that change in my updates. I have a bunch of stuff done locally that I haven't pushed to the master yet.

[Mottie]

By the way, do we really need to load another version of jQuery?

[silverwind]

Yes, I wasn't able to access the site's jQuery presumably because of Greasemonkey's sandbox.

[Mottie]

Ok, I got most everything working now.

I could not get the @run-at document-start to work consistently, so I left it set to document-end. I'll let you mess around with that to see if you can figure it out.

I left the version checking and loading of the script because I don't know how to access @require scripts - Chrome doesn't show them as loading, so I'm guessing they are saved in a sandbox which I don't know how to access.

[Mottie]

LOL, I just realized I forgot to add in a "toggle code wrap" option. I'll do that tomorrow! I'll let you mess around with the code for a while 😉

[silverwind]

I probably won't be able to do much til weekend, go ahead :)

[Mottie]

Ok, I added the toggle of long code button. The color between active & not active was subtle, so I made it turn green when active & red with disabled (only on hover). You might be able to come up with a better idea, so please feel free to change it. The wrap is active by default, when a "nowrap" class is added to the body, the wrap is disabled - see StylishThemes/GitHub-Dark@fe6d3f4.

Issues that still need to be addressed added to the first post.

[silverwind]

Nice! I'd actually prefer it to be on a per-box basis instead of on/off for all boxes on the page. I think a inline style with !important might be able to overrule a !important stylesheet.

Also added todo for Firefox checkboxes in OP.

[Mottie]

The only problem with that is that if you want to save the state, you'll need to save the url, code block index and state.

[silverwind]

No need to save a state. I'd say the checkbox in option controls the user's primary preference and the buttons override it through an toggled inline style. Once the page reloads, that style will be gone and the user's preference will take over.

[Mottie]

Ok, so just a temporary toggle then. You working on that, or do you want me to do it?

[silverwind]

Go ahead, I'm a bit busy today!

[Mottie]

And I'm a bit lazy today 😉

[silverwind]

Added another item to todo, here's what I mean, might be caused by my 200% page zoom:

[Mottie]

Hmm, maybe just make that a regular text input then.

[silverwind]

Yeah, that'd work I guess.

[Mottie]

Hmm, that wrap code change is a bit more than I wanted to tackle today... we can't use the nowrap class on the body then, and we'll need to figure out how to override the set style - I don't think inline with !important will override it.

I opened a new issue.

[Mottie]

In this last update, you can now use a keyboard shortcut to open the panel... g + 0 (within 1 second of each other). This combo is similar to the GitHub shortcuts available - press ? to see them.

[Mottie]

So I ended making these changes:

• Switching to only use a MutationObserver so the script works in Firefox now.
• Added a keyboard shortcut to toggle the style: g + - (minus) within 1 second of each other. I used minus since it is right next to the zero 😛
• Add & open panel even if you aren't logged in.

Hmm, maybe we should make a change log? LOL

[un1versal]

Would be nice if this ALREADY massive list had a small addition.

• Make compatible with stylish installed themes.

This would be ideal especially for those who like me, like to test the changes quickly via the browser editor/preview and also being able to update script on the fly from GitHub...

Atm its using stylish for testing fixes before submitting PR and you cant really edit the script updated via here as its stored in some compressed non-editable manner.

[Mottie]

Actually as @silverwind shared above about symlinks, Firefox adds the userscript to a gm_scripts folder... I don't know if you'll have the same tree, but mine is:

c:\Users\{user.name}\AppData\Roaming\Mozilla\Firefox\Profiles\{some.weird.value}.default\gm_scripts\

In there you'll find a GitHub_Dark_Script.db file which contains the stored css. I have no idea how to make that editable since it is a database file, but at least it isn't compressed.

I have to investigate more to find where Chrome stores its data, but it probably won't make much difference either.

[un1versal]

Why does it even have to go there? why cant it be same place stylish uses?

It would even be better is GH Dark Script had a edit button and it opened on your preferred editor 🐫

Camel unrelated....

[Mottie]

Because Stylish is a separate addon/extension from Greasemonkey/Tampermonkey. For security reasons, you don't want an addon to be able to figure out what other addons are installed.

[un1versal]

what a drag

well unlesss you add ability to read from databases or find a way to make the github.dark.css not be stored inside a database this idea of mine is dead or way too much work to implement...

how about adding some logic that detects if github dark is installed from stylish comparing the version and then updating that form this script, then one could update both and use the stylish installed file to test any fixes before making any pr... for extra credits even open the ff editor with that on.

[Mottie]

Stylish doesn't appear to have an API to allow that type of interaction.

[un1versal]

but the rest is possible or am I barking up the wrong tree?

[Mottie]

Rest of what? Every browser does something a little different.

I use the code paste textarea all the time, once you get the hang of it, it's easy.

[un1versal]

its not a simple thing, need to copy and paste the whole lot even if you change a single character all the navigation in between is time consuming.

The ideal situation would be to grab the very latest code and edit that test and do changes ontop of latest., as is you cant paste the latest github dark css into this script, as you explained they are both incompatible.

I think the best then is to have travis deploy stylish updates to stylish.org on the fly after each commit.
and make sure stylish supports the same amount of tweaking as script does.
Since editing and testing changes on a dime from stylish.org is 100% trivial, simple, fast and less code to maintain in long run.

But these are suggestions, anyway Ive nothing else to suggest this side... love the work though.

[silverwind]

I think the best then is to have travis deploy stylish updates to stylish.org on the fly after each commit.

What? Travis can interface with userstyles.org? Tell me more.

its not a simple thing, need to copy and paste the whole lot even if you change a single character all the navigation in between is time consuming.

Yes, I strongly prefer the Greasemonkey workflow of just saving in the editor and reloading too, but I'm afraid things aren't going to change unless someone starts working on external editor support for Stylish, which basically means replacing the SQLite storage with plain files (Should do it for the Chrome extension, because long-term, it's going to be in Firefox too).

[Mottie]

@silverwind check out this issue - stylish-userstyles/stylish#218 - I'm not sure how to change that extension setting.