Presenting: Stylefields - Access styles directly in your tiddler

Plugins
#5

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.

2 Likes
#6

Caveat emptor. Though, carpe diem too.

Thanks for your very detailed post. It is practically helpful!

Best, TT

#7

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!

1 Like
#8

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?

#9

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?

#10

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.

Do many S:/tags/Stylesheet tiddlers slow down TW?
#11

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.

#12

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. :medal_sports:

#13

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.

#14

@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

#15

Do you by “its” refer to multiple stylesheets in general or to the special stylesheet in my plugin?

#16

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 :woozy_face: )

Best wishes, TT

#17

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.

#18

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.

#19

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.

1 Like
#20

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 :smiley:

Just a comment
TT

#21

I would say they could be good friends without public legitimation of their relationship.

:heart: :heart: :heart:

Love,
Thomas

#22

It seems you use <pre> html-tag in your stylesheet tiddlers. It should not be done that way. Starting with TW 5.2.2 you can use the field code-body: yes.

There are very high chances, that a stylesheet gets broken, if it contains invalid CSS code. Browsers are very sensitive to invalid CSS syntax and stop processing the rest of the tiddler. This can cause hard to find problems.

3 Likes
#23

I did play with the plugin and clicked the delete button next to the CSS code field. … It seems the configuration is gone without any notification. :confused:

Why is the button even there? I think I would prefer a link button that opens the “linked” tiddler. I can still delete it in the normal way if I need to.

grafik
grafik819×701 31.4 KB

2 Likes
#24

I think there is 1 major problem with this type of editing the CSS code this way.

If a stylesheet can be opened and modified within the tiddler, it suggests, that the CSS code is related to that tiddler.

But that isn’t the case. The CSS code is still global – right?.

So if a user changes the code that it fits the current tiddler, it’s very likely that this change has side effects to other tiddlers, that the user doesn’t even know of.

May be it changes some styles that are used by eg: the “More : Tags” sidebar, which the user hasn’t even seen yet. …

Changes are made and several month later the “More : Tags” sidebar is broken. … Nobody knows why…

The result will be help requests here or at GG with broken TiddlyWiki core functions. Even worse if github bugs will be filed and core devs have to deal with them… These problems will be extremely time consuming to be found.

2 Likes