The TWaddler strikes again! Presenting…
Stylefields enable you to create styles and modify stylesheets directly in the tiddler you’re working in. Just where you need it!
IMO, the native stylesheets in TW are difficult to use and simply don’t encourage tiddlyfiddling. Chime in with your thoughts on the matter.
Very interesting, thanks for sharing, @twMat
Do you have a plan to keep your stylesheets up to date with future TW releases? Would that be easy?
Cheers,
Thomas
“My stylesheets” -? Are you referring to the demo stylesheets featured on the plugin page? Note that they are independent, and not included in the plugin. You could use stylesheets from some CSS framework instead if you wish.
Your question touches the raison d’etre for the plugin: The native TW stylesheet is a huge monolith. If a user customizes natively defined styles, then keeping such customizations up to date would be easier if the TW stylesheet was instead split up into multiple stylesheet tiddlers.
Ciao @twMat & @telmiger, I was immediately struck how you could use this to better understand TW CSS! So I think, beyond the immediate issue of changing some Tiddler looks, it might actually really help as a design tool.
I’m looking at using it to help more easily interactively shape the looks of a wiki and then update the “monolith” & remove the plugin?
Just a comment, TT
I guess that’s possible but it is probably better to investigate what tweaks you want and then put these in a separate stylesheet so they get higher precedence that the monolith. The Stylefields plugin could help in this if you create that separate stylesheet, and tag it $:/tags/Stylefieldso it shows in the listing, and then use this as the “pasting area” for your tweaked styles.
You could use the demo stylesheets from the page to investigate TW’s native styles BUT note that they don’t 100% map the native stylesheet! There are some bits in the original TW stylesheet that were not split out because I deemed them irrelevant to include as demos. There is also some minor rearranging of a few styles in the demo sheets. I’d say the demos cover 90% of the original content and that the parts snipped out are, on average, 95% similar. Caveat emptor.
Caveat emptor. Though, carpe diem too.
Thanks for your very detailed post. It is practically helpful!
Best, TT
Great tool! I share your frustration, and you can look at the system tab of any of my TiddlyWikis (for example this one) to see I have had to create long strings of StyleSheets. I have always hated the ‘monolith’ and found CSS to be a hassle to learn. (If it’s any consolation, Dynalist’s CSS is way, way worse).
This will go a long way to helping users learn and configure TW styling. Thank you for this tool!
I’m not sure I understand this plugin – yet.
Am I right in thinking it promotes the creation of stylesheets per tiddler? If so, does that scale in terms of performance?
Or (likely) did I miss something?
Kinda. There is a single “special” stylesheet. When you, in a tiddler, create a stylefield what you really do is you create another custom field in that special stylesheet, named like the tiddler! The text field of that special stylesheet iterates through and transcludes these fields so they become active styles.
But you can then access/edit all those fields from any tiddler. And you can access/edit full (common) stylesheets from any tiddler in the same UI.
I don’t know. But then why wouldn’t it?
Got it. Clever.
I think I read somewhere that excessive stylesheet tiddlers can impact performance. Each needs to be rebuilt and reapplied on every refresh of the wiki.
I, too, have a system that transcludes a bunch of tiddlers all destined to become part of a single actual stylesheet tiddler. While it’s “clean” and beneficial from a code management point of view, I’m no longer so happy it was the right move in terms of performance.
Let’s ask the core wizards: @pmario, @jeremyruston, @saqimtiaz.
I don’t know if it is more “excessive” that other stylesheet tiddlers? It’s a wikitext stylesheet, which I assume is more taxing than a static stylesheet, but it is only one stylesheet. Just like the TW monolith is one wikitext stylesheet.
If the monolith was split up, then it’d obviously make for more stylesheets. I guess there is some downside to that, just like for any big tiddler that is split up into several small.
Other than that, the custom stylesheets that the user can access via the Stylefields plugin would presumably still be around, regardless if there is a Stylefields plugin or not. The plugin just gives convenient access to them. One likely reason why people don’t have custom stylesheets is because it is tricky to create them because it is difficult to identify styles in the monolith and because TWs hackability is surprisingly lacking when it comes to stylesheets, IMO.
With that said; The transclusion iteration in the plugin stylesheet is possibly not very efficient (and there is one hackey bit that I don’t quite understand why it is needed: <span style="display:none">*/{}</span>) - but my “actual hope” with this plugin is that people begin to see how simple it should be to hack styling in TW and that there one day will be a proper native solution for this, or at least that the monolith is split up. Had that been the case, I would not have created the plugin… even if the “direct access” aspect is intriguing.
Yep. Got it. Same as mine, in the sources and the built stylesheet tiddler (hence my concern).
Not sure I personally agree with that – addressing the cascade is a skill, no doubt, but all CSS is like that.
I’m intrigued. Where’s that needed?
Noble aim. 
What do you mean with “addressing the cascade”? Say you want to create a button in the text field that looks and behaves like a typical toolbar button… can you do that easily? Would it not be substantially simpler if there was a separate stylesheet called “buttons” - you could then, for example, copy that stylesheet and prune it down to the relevant stuff and add your tweaks. This custom stylesheet could be added to the original, perhaps via a cascade field there (which, presumably, transclude it to cascade it). Or some such. Much room for improvement over current status.
Yeah… it is found in the discussed stylesheet at bottom in the main text field. (I misremembered the {} bit, this is apparently not needed. It was at one point.) If experimenting with it, then one can see how it affects the styled demo tiddlers.
@CodaCoder, just FYI, I might well use @twMat’s nice tool to help develop wikis. It has great merit for “playing more easily” with CSS in TW. It simplifies the process a lot.
Would it be performative? Dunno. TBH, I would use it to establish better CSS rules but then integrate them (i.e. overwrite stuff in Vanilla, or append them, as needed) and then likely remove the tool.
Just a comment, though I do remain interested if its overhead is significant in production wiki or not?
TT
Do you by “its” refer to multiple stylesheets in general or to the special stylesheet in my plugin?
I’m not so adept. Merely IF I use your plugin in production wiki would it slow them down? I know it is a fractious question as it is too vague. So–IF I went full-on with your tool and applied special rule sets to 50 tiddlers would it impact performance? (Merely trying to make the issue quantifiable 
)
Best wishes, TT
OK, first off, I don’t know and it would - just like for any plugin - probably take some real measuring to decide. But one could hypothetically erase all content in the special stylesheet tiddler in my plugin, or at least the “lower list” in it, and then only use the stylefields to access and edit separate stylesheets. That means it’s basically only an EditTextWidget to some tiddlers that happen to be stylesheets. I can’t see how that could slow anything down even hypothetically.
But it is a generally interesting question, outside of my plugin, how multiple stylesheets affect performance. I wonder if anyone did any tests. And difference between pure stylesheets and wikitext stylesheets. But browsers are designed for handling CSS so spontaneously I don’t think it has much performance impact compared to most other stuff we do in TW.
Addressing the task of applying styles to elements affected by the TW stylesheets.
Depends how you qualify “easily”. I first investigate using DevTools’ inspector and decide whether I need to extend or override by employing the correct specificity to achieve my aim. The folks behind the CSS specs are plotting and scheming to make this easier, too (though, TW itself will need to take steps, as well, I think).
Have you considered posting a fleshed out version of that to Github?
I do on occasion store styles in fields under some very specific (unusual?) circumstances. Even so, I’m not wholly enamored with the idea, or invested… yet.
Precisely. I’m concerned I’ve already made a mistake in my code. That’s obviously not a reflection on your plugin - not yet at least.
Where you need it. Exactly that. Except that it is IN-Tiddler. FYI I did comment to @telmiger that his excellent new work on CSS outwith the singular tiddler & your local approach, in the end, will need to Marry 
Just a comment
TT