[tw5] tw5-primer, Your New Favorite Theme/Plugin!

Google Group (Read Only)
#1

Hi everyone!

I have made yet another tw5 plugin, this one acting as more of a JS-inclusive theme for tw! The plugin, at this point, includes a Primer.css (https://www.primer.style/css) rendition of tw5 (primer is GitHub’s css library), which defaults to dark mode (light mode will be coming soon!).

I would love to have some testers for this; because of the need to re-write most of the primer stylesheet to fit tw5, and then add the correct classes to tw5 elements to have this styling… well… let’s just say it wasn’t easy, and required a rather unorthodox approach.

The plugin can be installed via drag-and-drop from https://tw5-primer.fnnsoftware.net, and the GitHub repo is at GitHub - flancast90/tw5-primer: GitHub's primer.css library... in tw5!. As usual, if you enjoy the plugin, share your thoughts… and a star :slight_smile:

#2

Hi Finn,

I appreciate your enthusiasm. … BUT … The implementation of this plugin is a hack from front to center. You use .innerHTML to change the DOM that has been created by tiddlywiki, with a timer that runs every second. Not only is .innerHTML a potential security risk, it ruins the TW refresh mechanism and adds a lot of unnecessary CPU load to the browser.

Everytime we click a button. TW redraws and restyles the different elements that are changed. ONLY those elements are changed, to make the mechanism fast. The browser has to do that, using the existing TW CSS and apply the styles.

Every second your plugin comes along and replaces the whole CSS with a 400kByte CSS form a CDN. Hardcore replaces DOM elements the TW core has drawn and restyles the complete page. (That’s where the blinking of the whole UI comes from. )

The most problematic thing is, that the whole thing completely breaks down in offline mode, or if you have a bad internet connection.

There is an easy test:

  • Go to the dev-console on your page F12

  • Select the Network tab

  • Search for the “No throttling” dropdown

  • Select “slow 3G”

  • Select Disable cache which is directly next to it.

  • Then reload your page.

It will need at least 10 seconds to load the page. … Now guess, how long it takes if you use the wiki offline

The core developers do everything to make the user experience fast. There is a lot of internal caching going on, to keep the page redraw as fast as possible.

The way it’s done in the plugin won’t work. It may be ok for empty.html, but once the wiki gets bigger there will be a lot of problems.

Try to download the whole wiki from tiddlywiki.com and drag & drop import it into your wiki. … See what happens.

Sorry but theming TW has to be done in the TiddlyWiki way.

I’m probably too harsh with my critiques, but please go to google and search for “.innerHTML security” and read some of the articles that come up.
Also have a closer look at the “” element, how it works and what it means for browser performance when a complete redraw is forced.

-mario

#3

Thanks for the criticism, @PMario. I do understand what you are saying; I’ve already begun to fix much of this. I intend to include the styles as a stylesheet (as opposed to inside the JS), and apply changes that way.

#4

@PMario, not sure if you saw it yet, but v1.0.1 and v1.0.2 are now out, making it less “hacky” (all css now), and no more .innerHTML.

On the note of the .innerHTML, I had a few questions, even though the plugin no longer uses it. According to both what I understand, and even the MDN doc you linked, innerHTML only becomes a threat when a user can make reflective OR persistent js change; The plugin (at v1.0.0) used only text I specified as innerHTML to append my stylesheet before tw’s so to avoid unnecessary !important’s and specificity in the CSS, and thus had no such “potential security risk”, unless I’m missing something.

Of course a user could change stuff on their end with Browser Inspect, but that’s only going to hurt themselves if they add malicious js. I think what you must have been saying is to avoid using unsanitised external .innerHTML additions, which, in this case, was not the case.

Thanks for your help again, and let me know what you think of v1.0.2 (https://tw5-primer.finnsoftware.net)!

#5

…

The plugin (at v1.0.0) used only text I specified as innerHTML to append my stylesheet before tw’s so to avoid unnecessary !important’s and specificity in the CSS,

I did see the !important declaration already. You and the users won’t be happy with it, since the theme CSS will be really hard to tweak by users.

There will be cases, where we see !important !important … Which is possible but similar to “a shoot in the foot”.

If you search Google for “CSS important harmful” you will find some articles.

One of the more resent ones: https://uxengineer.com/css-specificity-avoid-important-css/

!important has a reason why it exists. It can be used if there is absolutely no other way. … but … If you need it for almost every element in your CSS there is a major flaw in the whole system. IMO it will be better to rethink this.

I don’t have a solution, since I didn’t have a closer look. … but I can say one thing. Plopping an alien CSS toolkit onto TW will most of the time create more problems as it solves.

You did dig already into the TW UI and the CSS structure. IMO it would save you a lot of trouble and time, if you would try to understand it and use the possibilities that TW gives you, instead to try other “shiny” toolkits, that have been designed with a completely different philosophy and usecase behind it.

just my thoughts.
-mario